Ubuntu and Autologin to load OpenBox, XFCE, Others

Hello all,

I am working to rebuild one of my servers and thought I would share a tidbit of information. I decided to rebuild the server using as little as possibly needed, so I opted to use the Ubuntu 7.10 Gutsy Server install. This does not have any kind of desktop applications or X windows installed.

Below is information I found online for how to automatically have the server login and start an X session from the TTY1 default connection. This will then allow you to VNC into the server after the server boots up.

First note, to look at  this website to install the needed pre-requisites for a minimal system. Here you can choose which Window Manager to install as well. After you are done installing the window manager, continuing reading on below.

OK, now that you have that installed, note that this again was tested and works just fine on an Ubuntu 7.10 Gusty install. The guides that I found were for other versions, but they needed to be tweaked just a bit to work with 7.10.

follow these commands just after logging into the console:

sudo apt-get install gcc-3.4 build-essential
nano autologin.c

Inside the autologin.c file, this is the code that is entered; substitute USERNAME with your login username.

int main() { execlp( “login”, “login”, “-f”, “USERNAME”, 0); }

Continuing on at the command line:

gcc-3.4 -o autologin autologin.c
sudo cp autologin /usr/local/sbin
sudo nano /etc/event.d/tty1

In the tty1 file, go to the ‘respawn’ line and type this exactly in. ‘respawn’ needs to be on a line by itself and then type the line below it. Note that you should be a # in front of the current respawn.

respawn
exec /sbin/getty -n -l /usr/local/sbin/autologin 38400 tty1

That is all! You should be able to reboot your PC and it automatically login with the username you specified and start the Window Manager.

It is then safe to remove gcc-3.4 and build-essential if you had to install it for this purpose only.

sudo apt-get autoremove gcc-3.4 build-essential

Working with VMWare Server GSX (Free Version)

For the past few weeks, I have been doing a lot of development and use of the VMWare Server GSX edition; the edition that is freely available for download from VMWare's website.

VMWare is a product that establishes 'vitualization'. This will allow you to run guest or virtual operating systems on top of a host operating system. After a lot of problems with the software, I decided it would be good to report on my findings to help others online as well.

Originally, the plan was to install VMWare server on a 64-bit AMD dual-core processor using Windows 2000 as the host operating system. From there, I would then create a guest or virtual server running Ubuntu Linux. The reason for this is because Linux has many great tools that are all free for use. I was going to use Linux to do content scanning for incoming e-mails using the Exim4 mail server, spamassassin for spam checking, and ClamAV for virus checking.

However, I immediately began to run into problems after I installed VMWare Server GSX on a Windows 2000 host operating system on a 64-bit processor. The operating system would randomly shutdown and would get errors in the event log stating 'the previous shutdown was unexpected' and would list the time and date. In addition, there would also be 'the computer has rebooted from a bugcheck.'

After speaking to a professor at my university, he informed me that VMWare had some trouble with 64-bit processors. He informed me that VMWare had troubles with stability when the host OS was 32-bit and the virtual server/guest OS was 64-bit. However, this did not describe my problem as I was running 32-bit versions of both. But, he did tip me in the right direction.

It appears that the problem lies with Windows 2000 and the 64-bit processor itself. Although the dual-core processor I have supports virtualization, it was causing some kind of problem. Instead, I installed Ubuntu Linux as the host operating system and then installed Windows 2000 as the guest operating system/virtual server. I have now been running in this configuration for over a week and the system is rock-solid stable.

To do more research, I installed VMWare on my second server that runs Windows 2000 as well, but has a 32-bit AMD XP2800+ processor. There has been zero problems with this server when using Windows 2000 as the host operating system and Ubuntu Linux as the guest operating system/virtual server. This has also been running for multiple days as well with rock-solid stability.

Some of you may think "oh, it must be bad memory or a bad hard drive." Not the case. I did a full check on the SATA hard drive and ran xmemtest86 on the memory and both came up flawless with no problems.

So, after my own research, I believe that VMWare Server GSX does not work well on Windows 2000 host operating system on a 64-bit processor. It works just fine as 32-bit Ubuntu Linux as the host operating system on a 64-bit processor.

Near Immediate Replication with NT File Replication Service / NTFRS

After fixing the sessiondata issue with php with multiple servers, I then noticed that replication between the two servers was very slow and sluggish – but not because of this issue.

Replication would take place on the average – every 15 minutes by default.

I use the built-in Windows 2000 NT File Replication Service – or ntfrs – to replicate files between the two computers. This way, it keeps everything identical between the servers. Before, 15 minutes for replication wasn't a problem – but when dealing with session data and changes, this was becoming an issue and giving "Invalid Session" messages in Joomla if the session file had not replicated yet.

After doing more research, I discovered that by adding two registry entries to the ntfrs parameters.

Here is where they are added: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFrs\Parameters

Add these two DWORD Entries: "DS Polling Short Interval in Minutes" "DS Polling Long Interval in Minutes"

The minimum for these values are 1 minute; the default (which means these entries don't exist) is five minutes. I set BOTH of them to one minute. Replication now happens sometimes within seconds – but no more than one minute from my tests.

Basically the difference between the two entries above is this – Whenever the file replication service notices that there are a consecutive eight short polling times with no changes, it will change over to the long interval and continue checking with the long interval time. During the long interval time if a change is noted, the change will be replicated at the end of the long interval – and then the service will revert back to the short interval for eight consecutive times. The process starts over again.

By setting both of the above entries to one minute each, they basically are the same thing and the interval remains constant – and your files are replicated every one minute. Of course, if you have a huge file that takes more than one minute to transfer, that won't happen. These intervals are just the periods for how long the service will check for file changes in the replication share.

This is not real-time replication; it isn't exactly immediate, but it definitely is a speed up and boosts the performance of replication. I have a very odd use of this replication feature with moving web spaces between servers, but it works.

Joomla Admin Fix

After adding more clients to my list, I noticed that I began getting problems with Joomla. Recently I upgraded to Joomla 1.0.14 from Joomla 1.0.13.

I host web sites on two separate servers that are connected by a link. In the case that the server goes down either from a hardware issue or a problem with the Internet line, the other server will pickup without missing a beat! All web space is replicated and database information is replicated.

However, I started to get "Invalid Session" errors when logging into the admin ports for Joomla. After doing some research, everyone was stating to ensure that you have the session data in the php.ini file to use "files" and also have the path writeable to everyone. Of course, the path also needs to exist! Everything checked out fine there.

Well, after more digging, I discovered that this sessiondata folder was stored on the regular drive of each server and was not in a location that allowed for replication. I then updated the path in the php.ini file and created a new directory that existed within the replication partition. Restarted IIS on both servers after updating the files. Now, I see the session files being created and seconds later, transferred and showing up on the other server. No more "Invalid Session" errors with Joomla.

This is something that many other people may have trouble with as well with some of these big-name web hosters. If the data is not replicated immediately and you jump to another server – POOF! You will get "Invalid Session" from your Joomla administration portal when attempting to login.

Don’t Let Memory Fool You…

Quite a while ago, I upgraded the memory in the Paris server. I was thinking that it wasn't exactly needed because the memory monitor still showed that there was at least 100 MB of the memory available.

The Paris server was built with a 1 GB memory stick for later expansion if needed. I installed another 1 GB memory stick on the server, and to my surprise, there is now only about 300 MB of free memory after the server is on for at least 24 hours.

So, out of 2 GB of memory that was installed, it is using 1.7 GB of it. How did it survive with only 1 GB installed? I guess it was using the swap file (virtual memory) on the server more than it was reporting. Or maybe now that more memory is available, the server is taking advantage of storing more data for quicker retrieval.

RAM operates in nanoseconds (ns) for access times. Hard drives also operate in nanoseconds as well. However, memory access times are much faster than hard drive performance. Therefore, this memory upgrade improved system performance all around.

Josh with Midwest First also installed more memory in his web server. He only had 256 MB starting out and added more. His website loading times reduced dramatically.