Redirect all shell output

BASH Shell Redirect Output and Errors To /dev/null

How do I redirect output and errors to /dev/null under bash / sh shell scripting? How do I redirect the output of stderr to stdout, and then redirect this combined output to /dev/null?

You can send output to /dev/null, by using command >/dev/null syntax. However, this will not work when command will use the standard error (FD # 2). So you need to modify >/dev/null as follows to redirect both output and errors to /dev/null:

$ command > /dev/null 2>&1
$ ./script.sh > /dev/null 2>&1
$ ./example.pl > /dev/null 2>&1

You can also use the same syntax for all your cronjobs to avoid emails and output / error messages:

@hourly /scripts/backup/nas.backup >/dev/null 2>&1

Tags

Related Posts

Share This

Plaintext authentication disallowed on non-secure (SSL/TLS) connections

If you, or your clients, are unable to login to your/their email accounts and the system shows this error message:

Plaintext authentication disallowed on non-secure (SSL/TLS) connections

If you do not want to use SSL/TLS connection to get your email, and to disable SSL/TLS secure connection, do the following:

1. Edit dovecot configuration file: /etc/dovecot.conf using your favorite Linux editor such as vi or pico.

2. Change the value for this directive from:

disable_plaintext_auth = yes

TO:

disable_plaintext_auth = no

3. Restart dovecot

( Note:  This is a stupid thing to do.)

Tags

Related Posts

Share This

How to set up WebDAV hosting on Apache – TechRepublic

Original: How to set up WebDAV hosting on Apache – TechRepublic.

WebDAV (Web-based Distributed Authoring and Versioning) is a way to share files over HTTP, much like you would use Samba or NFS. It has more limitations, and less speed, than filesystems like Samba or NFS, but with the proliferation of web servers and the ability to reach websites from multiple clients in various locations, WebDAV certainly has its appeal. Unlike Samba or NFS, which are best suited for local area networks, you can use an HTTP server anywhere in the world and likewise access it from anywhere.

WebDAV support is also baked right into most modern operating systems, making it extremely easy to access as a client. Setting it up on the server, however, may be more of a challenge. Certainly setting it up correctly can be.

Using Apache on Red Hat Enterprise Linux 5 (or CentOS 5) as an example, let’s look at setting up a WebDAV server. First and foremost, you will need mod_dav and mod_dav_fs support, which can be found in the httpd package; if you have Apache installed, you will have support for WebDAV already available (other distributions may package WebDAV support modules separately, such as apache-mod_dav). The first step is to create /etc/httpd/conf.d/webdav.conf which will be where we configure WebDAV. The reason we are putting our configuration file there is due to this gem in /etc/httpd/conf/httpd.conf:

Include conf.d/*.conf

This tells Apache to automatically pick up all configuration files (*.conf) in /etc/httpd/conf.d/. The contents of /etc/httpd/conf.d/webdav.conf will look similar to this:

<IfModule mod_dav.c>
    LimitXMLRequestBody 131072
    DavLockDB /var/dav/DavLock
    Alias /dav "/srv/www/dav"
    <Directory /srv/www/dav>
        Dav On
        Options +Indexes
        IndexOptions FancyIndexing
        AddDefaultCharset UTF-8
        AuthType Basic
        AuthName "WebDAV"
        AuthUserFile /etc/httpd/conf/dav.passwd
        Require valid-user
    </Directory>
</IfModule>

This sets up the required WebDAV settings necessary to make it work properly. Here we have defined a number of things; one that is important to note is the location of the DavLockDB file (this must be writable by the user running Apache — usually apache or nobody). The directory storing the lock file needs to be writable, so create a new directory specifically for this purpose:

# mkdir -p /var/dav
# chown nobody:nobody /var/dav

You will also want to ensure that /srv/www/dav is writable by the user running Apache as well:

# mkdir -p /srv/www/dav
# chown nobody:nobody /srv/www/dav
# chmod 755 /srv/www/dav

Finally, you need to create the password file for authentication. In the above example the password file was specified as /etc/httpd/conf/dav.passwd, so use htpasswd to create it:

# htpasswd -c /etc/httpd/conf/dav.passwd [user]

You will be prompted for [user]’s password and then htpasswd will create the file. At this point you can restart Apache:

# service httpd restart

You can now point a web browser to http://yoursite.com/dav/ and it should prompt you for a login. You won’t be able to do anything special in the web browser, but you can use another WebDAV client to try uploading and downloading files, such as cadaver:

# cadaver https://yoursite.com/dav
Authentication required for Private on server `yoursite.com':
Username: user
Password:
dav:/dav/> ls
Listing collection `/dav/': succeeded.
Coll:   omnifocus                              0  Aug  8 14:30
        somefile.txt                         115  Jul 17 15:03

For more security, wrap WebDAV up in SSL by adding it to an appropriate SSL-based virtual host. This will encrypt your password and data-in-transit.

This should also work with most other Linux distributions using Apache, possibly changing some paths to configuration files or package names. All in all, setting up WebDAV doesn’t have to be difficult, but all of these steps are required, otherwise some WebDAV clients will fail with inexplicably weird errors. This also provides a quick and easy way to store files in a remote location, securely, with the ability to obtain them from anywhere.

Get the PDF version here.

Tags

Related Posts

Share This

Negotiation: Discovered File(s) Matching Request: None Could Be Negotiated

Original: Negotiation: Discovered File(s) Matching Request: None Could Be Negotiated.

Posted June 24, 2011 at 9:30 AM by Ben Nadel

Yesterday, I lost at least two hours trying to figure out why my local copy of a website was throwing 404 (File Not Found) errors. We had just implemented some URL rewriting on the production site and things appeared to be working fine. On my local computer, however, the URL rewriting would only work for some URLs. After a lot of Googling, a little bit of a meltdown, and walk around the block to clear my head, I finally figured out what was going wrong: MultiViews.

For this particular website, we were using Apache to create a more resource-oriented URL scheme. So, where we used to have URLs that looked like this:

/users.cfm?action=view&id=15

… we were going to be moving to a URL scheme that looked more like this:

/users/15/view/

For the majority of URLs in the application, this was working fine. But for a few URLs, this came back as a 404 File Not Found error. When I looked in the Apache error logs, I kept seeing log items like this:

[Thu Jun 23 16:55:06 2011] [error] [client 127.0.0.1] Negotiation: discovered file(s) matching request: /Sites/something.com/users (None could be negotiated).

My experience with the Apache HTTP server is somewhat limited; as such, this error didn’t really mean anything coherent to me at the time. And, much of my Googling wasn’t really yielding anything too valuable. Finally, however, I did come across a threaded discussion that mentioned “MultiViews”. On the Apache website, the effect of Multiviews, as listed under Content Negotiation, is as follows:

If the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements.

This is exactly what was happening! When the user requested the non-existent URL:

/users/15/view/

… Apache was finding this physical file on a per-directory basis:

/users.cfm

… and then using Content Negotiation to try and figure out which file it should served up based on the request headers. And, since I didn’t have any file types configured for content negotiation, Apache didn’t know how to respond and just returned a 404.

When I checked in my Virtual Host configuration, sure enough, MultiViews was enabled:

 Launch code in new window » Download code as text file »

  • Options Indexes FollowSymLinks MultiViews

The moment I removed the MultiViews option:

 Launch code in new window » Download code as text file »

  • Options Indexes FollowSymLinks

… everything started working fine.

This goes to show you how bad it is to simply enable settings when you are not sure what they do. I’ve grown to love my Apache server; but, clearly, there is so much more that I need to learn about it. When it works, it works; but, when it doesn’t, I have no idea what’s going on.

 

Tags

Related Posts

Share This

Setting up an SSH tunnel

This howto page will provide instructions on how to reach services running inside a firewall from outside of the network by using the Putty SSH Client and SSH Port Tunneling.

Requirements

Download Putty.exe.

Port Tunneling

Launch Putty. Different categories will be listed on the left side, click on Connection > SSH > Tunnels.

Under Add new forwarded port:, enter the following information:
Source port: [port on local machine]
Destination: [hostname of remote machine]:[port on remote machine]
Click Add.

It would look like this if I wanted to forward port 80 on the CCIS webserver to 8080 on my local machine:
CCIS Webserver Tunneled to port 8080

Clicking Add will add it to the list of forwarded ports:

Connecting

After setting up the port tunnel, select Session from the category list on the left side.
Enter login.ccs.neu.edu in the Host Name (or IP Address) field and click the Open button at the bottom right.

Select Yes if prompted with this window:

Use your CCIS username and password when prompted to login and your port tunnel will be setup.

Utilizing the Port Tunnel

Now that the port is tunneled, you can connect to it using localhost:[port forwarded] where [port forwarded] is the local port you chose earlier.

In our previous example we forwarded port 80 on www.ccs.neu.edu to localhost:8080. We can now open up a web browser and browse to localhost:8080 to see it:

MSSQL Over an SSH Tunnel

The steps are practically the same as tunneling any other service, except the port you will tunnel is 1433. When connecting from MSSQL Management Studio, the connection host will be 127.0.0.1,[port you forwarded] . Notice the comma between the ip and the port number, this is very important. The following screens will show the proper setup:


And there you have it, you should now be able to SSH Tunnel to any service inside a firewall.

Tags

Related Posts

Share This