Archive for the ‘unix’ Category

Remove Tilde From URL On OS X Personal Web Sites

Saturday, August 14th, 2010

I’ve recently been helping a friend with some web site stuff. Nothing too complex, just some php that results in some html and css.

Continually ftp’ing the files back and forth to my ISP hosted account was becoming labour intensive, so I figured I would just use the apache web server built into OS X on my Mac Mini.

Some notes:

The main apache config file is located at:

/etc/apache2/httpd.conf

Each user has a personal apache config file that specifies the location of their personal web folder location. This file is located at:

/etc/apache2/users/<username>.conf

Each user/logon gets a folder called ‘Sites’ in their home location (so /Users/<user>/Sites/). This folder is the root folder of your personal web folder name space.

When you access the site, the url to use is:

http://servername/~username

If you don’t like the tilde character (~) being part of the url, you can get around it by editing the users personal apache config file. Add the following to the top of the file:

/etc/apache/user/<username>.conf

Restart apache (either from the Preferences panel, or with ‘apachectl restart’ and you should be good to go.

So my logon on my Mac Mini is Scott. The file I need to edit is:

/etc/apache2/users/Scott.conf

And I need to add the line:

Alias /Scott “/Users/Scott/Sites/”

I also add:

Alias /scott “/Users/Scott/Sites/”

So I don’t have to worry about case sensitivity. So now instead of using:

http://mymacmini/~Scott

you should be able to use:

http://mymacmini/scott

Correct ESX NTP Time Periodically

Friday, May 14th, 2010

Just had an odd one. Everytime I rebooted any one of my Windows VM’s, when it came back up the clock would be out by a varying amount.

VM’s on the same physical host would be out by identical amounts, but Vm’s on different physical hosts would be out by different amounts.

The physical VM host servers are all running NTPd, and are configured to sync to the pool.ntp.org server lists, so I thought this was all sorted, seems I was wrong.

Each physical box, even though it was syncing with NTP peers in the outside world, was experiencing varying degrees of skew on the clock. The amount was up to 20mins across all the physical nodes.

To correct this, I have created a cron job on each server with the following entry

0 9 * * * /usr/sbin/ntpdate -s -b -p 4 -u 0.pool.ntp.org

Now the server will correct the clock skew once each day at 9am, and hopefully now I can forget all about this :-?

Change Ubuntu Default ‘ls’ Command Alias…….

Tuesday, April 27th, 2010

Change Default Ubuntu Aliases

By default Ubuntu (plus several others) change the ‘ls’ command to be an alias that colour codes the output. While I’m sure this is great for many people, I don’t like it :o(

I like back background, lime green text, directories indicated with a ‘/’ character at the end, and hidden files to be shown.

To change the default, you need to make the same change in a couple of places…….

Firstly, in your home directory. Edit the hidden file ‘.bashrc’. Find the line that reads alias ls=’ls –color=auto’ and comment it out with a ‘#‘ at the start.

Then add a new line (above or below, does not matter) with the following

ls=’ls -aF’ (in this case, ‘a’ shows all files including hidden ones, ‘F’ indicated a directory by adding a trailing forwardslash ‘/’ after the directory name

This will change your login only. If you also want to change the root ls alias you will need to follow the same steps for the file /root/.bashrc, but you will need to either use sudo with your edit command, or su to root and then edit.

The last place you may wish to edit is the skeleton template file used for all new users. This is located at /etc/skel/.bashrc. Again, eidt the file with the changes above, and all newly added users will recieve a copy of the file and have their ls command alias set to your formatting (if you so wish).

Enable The ‘root’ User Account In Ubuntu…….

Friday, March 12th, 2010

I like consistency. It makes things easier, and me faster and more accurate/efficient/amazing to watch etc. etc.

As Ubuntu is the 4th Linux distro I have ever had to work with (first being OpenBSD, the FreeBSD, then Red Hat) I was getting a little annoyed that after an install ‘su’ did not work as I was previously used to.

Ubuntu chose instead to lock the root account out and force you into using the ‘sudo’ command. This means that to do anything as ‘root’ you use

sudo <command to run>

The system will then prompt you for *your* password and, if you have sufficient permissions in the sudoers file, will execute the command you provided with root level permissions.

There are of course some benefits, mainly centered around security. But there are also some drawbacks such as having to maintain the sudoers file, and command output redirection. But given that OpenBSD is considered one of the most secure Unix operating systems around and they don’t feel the need to do it this way, I like to change this behaviour immediately after the first post install reboot.

To enable the root account, logon to the system with your account and run

sudo passwd root

The system will prompt you for *your* password. It will then prompt you to enter a new password for the root account, and then to confirm it a second time. Once this is done you can just switch to the root use using the plain old ‘su’ command.

Oh, and if you’re worried about being able to log directly onto SSH as the root account, simply edit

/etc/ssh/sshd_config

and change the line

PermitRootLogin yes

to

PermitRootLogin no

This will ensure that you have to login as a normal user and su to root from remote connections.

If you wish to revert back to the default Ubuntu behaviour, simply run (under your own logon)

sudo passwd -l root

Make Nagios Web Interface Read-Only…..

Friday, March 5th, 2010

Even though we’re not a massive company (less than 50 butts on seats) we do have quite a bit of kit in an environment that is growing ever more complex.

To help we use Nagios to monitor key systems and services and to alert us via email when issues arise (and hopefully we can correct them before the masses notice)

My boss decided he wanted to share our Nagios screens with others (well, his boss) and so I installed a workstation with x2 flat screens lofted up on high so they could be seen from a distance.

But, I had a slight snag. We use authentication on Nagios and the account used for viewing the web console had enough permissions to be able to execute the host commands listed on the right hand side of interface (shown below)

This meant that should any passer by wish to, they could click the url link to say, turn off a check that was failing (not that any of our users would do such a thing !). So I needed a way to make the web interface either not display those links or be read-only for those links, essentially prevent people from altering the configuration.

Peeking through the config files for Nagios, it seems my predecessor had the same idea at some point, but had not quite managed to pull it off. Inside the cgi.cfg file (which was located at /usr/local/nagios/etc/cgi.cfg) are the following lines

default_user_name=

authorized_for_system_information=

authorized_for_configuration_information=

authorized_for_system_commands=

authorized_for_all_services=

authorized_for_all_hosts=

authorized_for_all_service_commands=

authorized_for_all_host_commands=

The ones of interest are :

authorized_for_all_services=

authorized_for_all_hosts=

By adding a user to these x2 lines *only*, the urls on the pages for running commands and viewing/modifying the config do not work and give a permissions error

You will also need to add the name you add to those x2 line to the /usr/local/nagios/etc/htpasswd file as well

Now, even though you can still see the command urls on the pages, you get this if you try to click them

nagios says no

So, how far had my predecessor gotten ? Well, something I take for granted that I guess he did not know, the list of names supplied should be comma seperated with no space between them

Easy when you know how :o)

Apache2: No Listening Sockets Available…….

Friday, January 8th, 2010

Following on from the issue(s) I had with my OpenVPN server, I was still not happy/confident that in the event of a reboot or restart for any reason (wether deliberate or unintentional) all the necessary processes and services would startup successfully without some post boot intervention.

This in mind, I decided to create another server to transfer the live service(s) onto so I could get some much needed downtime on the existing server. Owing to the lack of another physical machine to do this with, I decided to create an virtual machine on our ESX cluster.

The initial steps were pretty easy, create a VM with x1 Vcpu, 1GB RAM, 30GB vdisk and x2 network interfaces. I installed Ubuntu server 9.04 i386 from the .iso and enabled LAMP and SSH. Installation completed and the system rebooted. Watching the console I saw that everything started at bootup time as it should.

Next step was to copy the websites across from the live server to this one. I installed NFS and mounted /var/www from the live server and copied all the sites across along with the relevant config files. I modified the config files to allow for the change of ip address and then restarted the system.

And that was when it started to go wrong. I only caught a glimpse of the error the first time I restarted the system. After reboot, I logged in a checked and apache was not running. Looking in /var/log/syslog did not show any clues why, even the error message itself did not seem to have been captured.

So I rebooted again and watched the console carefully, and this time saw the error :

apache2: no listening sockets available

along with

could not bind to address x.x.x.x:80 (where x was the ip address of the server)

Googling this made mention several times of other processes or programs perhaps using and blocking the socket/port in question, but this was happening at boot time, nothing else really had a chance to be up and running yet ? to test, I tried starting apache from the command prompt after bootup and it started fine, so what was going on

The main difference between this server and the live one was that this one was in a VM. Looking at the runlevel start scripts I noticed apache gets in there really early with S02apache2. Given my previous post where OpenVPN was trying to start before bridging on the live server, I wondered if perhaps the interface that Apache was trying to bind to was perhaps not quite ready at the time it tried during the boot process.

So I moved S02apache2 to S09apache2 for all runlevels and rebooted the VM again. Result, Apache was now loading as part of the boot process with no errors or manual intervention required.

So if you are also having issues with processes that do not start at boot time, but start fine after boot when you initiate them from the command prompt, you may just need to move them to a little late in the boot process to give other things time to start up beforehand.

I don’t profess to be the best system admin in the world, but I always get to the cause eventually :o)

OpenVPN TCP/UDP: Socket Bind Failed…….

Tuesday, January 5th, 2010

My faithful office OpenVPN server required a reboot before the start of the Christmas holidays to install some updates and patches.

The server came back ok and seemed to be fine, so I thought nothing much of it and went home for a few days off……until the emails started arriving from users stating they could not connect to the vpn from their homes !

So Boxing day I trudged through the freezing cold to the office to logon to the box locally to find out what was going on (was obviously something big as I could not connect in either).

Initial findings were that the OpenVPN process did not seem to be running….? so I issued ‘/etc/init.d/openvpn start’ and it started fine. so, what caused it to stop running ? peeking into /var/log/messages.log I found the following lines


TCP/UDP: Socket bind failed on local address x.x.x.x:1194: Cannot assign requested address

Exiting

Googling this error revealed a few other people had also had this issue, but there was nothing definitive as to the cause.

Was another process grabbing port 1194 and preventing openvpn from starting up ? I decided to reboot the server to check, and there it was again, the openvpn process failed to start with the same error message, but nothing else was using port 1194 when I checked, and when I started openvpn manually after reboot it came up fine, what was going on ?

Going back over the installation steps I took to install and setup openvpn, I remembered that it requires the use of the bridge-utils app for bridging the ethernet interfaces on the server. I wondered if there was some kind of race condition happening whereby birdge-utils had not started in time for openvpn to bind to the virtual tap interface that gets created.

So I stopped openvpn with ‘/etc/init.d/openvpn stop’ an then stopped bridging using ‘/etc/openvpn/scripts/bridge-stop’

I then tried to start openvpn without bridge-utils running and got the same error that I was seeing in the syslog when I rebooted the system. So that was the problem, but how to fix ?

First off I need to check which run levels openvpn and bridge-utils were being loaded at. ‘checkconfig -l | grep -E “openvpn|bridge”‘ showed both loading at runlevels 2,34 and 5.

Looking into the run level 5 in /etc/rc5.d I could see the x2 scripts used for starting up these processes at boot time, S01openvpn and S06bridge-start. As the startup scripts execute in numerical order, openvpn was being started before bridge-start. Simply moving S01openvpn to S10openvpn was all that was required. A subsequent reboot of the server showed that the openvpn process was already running when I logged on to the server post boot.

then the trek back home again in the freezing cold :o(

Refreshingly Secure…….Part 3

Monday, January 4th, 2010

For the final part of reminding myself how to secure a linux website, I need to include the bit on how to force unsecure traffic to be secure. This is done using rewrite rules to rewrite the url path from http:// to https:// you can make the whole site redirect to secure, or just certain subsections of the site.

To force the whole site secure, you first need to run x2 versions of the site, a secure version listening on port 443 and a non-secure version listening on port 80. You then need a rewrite rule on the port 80 site that basically say if this url is http:// rewrite the url to be https://

The config to do this is below and needs to be included between your <VirtualHost> tags on the non-secure site config


RewriteEngine On
RewriteCond %{SERVER_PORT} !443
RewriteRule (.*) https://www.sporticia.com/ [R]

This basically says if the url is not on port 443 then rewrite the url to be https://blah

As the re-write rules are written using regular expressions, you can actually do some pretty complex stuff, examplex of which you can find here and also here

padlock

Refreshingly Secure…….Part 2

Tuesday, December 22nd, 2009

So we now have our private key .key and our public key .crt (or something to that effect).

Now we need include the files in the apache config. place the .key and .crt files where you can find them (I use /etc/apache/ssl-certs/). now you need to edit your apache config file. I’ve included a dummy version below to show you what to add and where.

You will need to add ‘SSLRequieSSL’ in between the <Directory> </Directory> tags to tell apache that the content from this directory should be encrypted, you will also need to alter the port from :80 to :443

You then need to include

SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache/ssl-certs/www.sporticia.com.crt
SSLCertificateKeyFile /etc/apache/ssl-certs/www.sporticia.com.key
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown

to provide the location details for the private key and the certificate to be used.

The whole thing should look something like this


<VirtualHost 192.168.1.10:443>
ServerName www.sporticia.com
ServerAlias sporticia.com
ServerAdmin test@sporticia.com

DocumentRoot /var/www/sporticia.com

<Directory /var/www/sporticia.com>
SSLRequireSSL
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ErrorLog /var/log/apache/www.sporticia.com.com_error_log
CustomLog /var/log/apache/www.sporticia.com_access_log common

SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache/ssl-certs/www.sporticia.com.crt
SSLCertificateKeyFile /etc/apache/ssl-certs/www.sporticia.com.key
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown

</VirtualHost>

Restart Apache (using either ‘apachectl restart’ or ‘/etc/init.d/apache restart’) and you should now be able to browse the site using ‘https://sitename’ and you should have the little padlock icon to indicate the site is secured with an SSL certificate.

Note that while this will permit you to browse the site using https, it will not force the browser to https, if anyone tries to access the site using http they will get a 403 forbidden page.

Next post will show how to force the broswer to use the secure version of the site

padlock

Refreshingly Secure…….Part 1

Friday, December 18th, 2009

Grrrrrr, some of our SSL certificates had expired on a linux server today. And, like very time I have to renew an SSL on a linux machine, there was a bit of trial and error as I tried to remember how I did it the last time.

So here’s a refresher for me and notes for anyone doing this for the first time.

SSL uses x2 keys for encryption and decryption. you create the private key on your linux server, and then use this to create a certificate signing request (csr). you then use the csr with a 3rd party certificate authority to create your certificate or public key.

the math involved is pretty heavy but this guy explains it really well using a tiny prime number so you can follow (hopefully).

First, generate your private key on the server using

openssl genrsa -out <sitename>.key 2048

replace <sitename> with the name of your site, this will help you to tell different keys apart. The 2048 at the end says how many bits in size you want the key to be, no smaller than 2048.

Next, we use the private key to create the certificate signing request (csr)

openssl req -new -key <sitename>.key -out <sitename>.csr

openssl will ask you some questions about the csr, important notes:

The country code is ‘GB’ for the United Kingdom, not ‘UK’ !!!!

The ‘Common Name’ is the url for the site you are securing (i.e. www.sporticia.com)

Remember the password you use when you create the csr, you will need it to install the certificate you create from the csr

BACKUP YOUR .key and .crt files ! if you loose them, you will have to start all over again

You can now take your .csr file along to a 3rd party certificate authority (Thwate, Go Daddy, VeriSign etc. etc.) and use it to generate your private key (.crt or certificate file).

Next post will explain how to use the keys with apache to secure the site.

padlock