Contents |
Default installation of Ubuntu 6.06 has multiple getty entries in /etc/inittab. This can lead to rapid growth of log and /var/log/wtmp files (wtmp file keeps tracks of login/logouts)
To eliminate this problem, edit the /etc/inittab file and comment out all but the first (tty1) getty entries:
... # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # 1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 ...
Even if you only use the GUI (Gnome, KDE, XFCE) to log into your machine, it's always a good idea to leave at least one graphical console open in case of emergency (X server freeze, display corruption, runaway GUI app). You probably don't need the tty2 - tty6 getty entries enabled unless you're running without a GUI.
After editing, run
telinit q
to re-read inittab. (tip from forum users acasafemto and sleddog)
For more log managing, install logrotate
By default Ubuntu installation shows time in UTC. To easily set it to correct zone link the right file from /usr/share/zoneinfo/ into /etc/localtime. For example, for Central timezone use /usr/share/zoneinfo/America/Chicago.
Alternatively, the tzconfig utility can guide you through all available choices.
If during compilation you see errorno errors, you probably should create local config file with include path fix:
echo gcc -O2 -include /usr/include/errno.h > conf-cc
The standard library reads DNS settings from /etc/resolv.conf. On my standard VPS install of Ubuntu this file is created dynamically by the resolvconf package which is designed to allow alternative network configurations to specify DNS settings (eg. laptops with static IP at home and DHCP at work). You might google and find some advice that the right place to put this in the /etc/network/interfaces file. Under the virtualisation software used by VPS this file is dynamic too, but managed by the host operating system. Because each customer wants control, I don't believe VPSLink can put standard settings in these files.
Resolvconf builds the /etc/resolv.conf file by concatenating the files in /etc/resolvconf/resolv.conf.d. The file original probably contains your starting /etc/resolv.conf. However, it is head, base and tail plus interface-specific settings (dns-domainnames from /etc/network/interfaces) which are used to recreate /etc/resolv.conf on reboot.
My solution was to put the nameserver settings from original into base (I don't need to search spry so dropped it). You don't need to reboot - just update using resolvconf -u.
root@vpslink:/etc/resolvconf/resolv.conf.d# cat original search spry.com nameserver 66.249.3.10 nameserver 66.249.3.11 root@vpslink:/etc/resolvconf/resolv.conf.d# nano -w base root@vpslink:/etc/resolvconf/resolv.conf.d# cat base nameserver 66.249.3.10 nameserver 66.249.3.11 root@vpslink:/etc/resolvconf/resolv.conf.d# resolvconf -u root@vpslink:/etc/resolvconf/resolv.conf.d# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 66.249.3.10 nameserver 66.249.3.11 root@vpslink:/etc/resolvconf/resolv.conf.d#
If VPSLink changes their nameserver locations it will be a major problem, but I am no more exposed than before. I think VPSLink should consider changing the standard Ubuntu image to fix this so that DNS doesn't break on the first reboot.
|| Ubuntu In Flashback ||
LAMP on a Link-1 isn't recommended due to the limited RAM on the Link-1 plan. Preliminary tests show that less than half a dozen users can overwhelm a wordpress blog hosted on apache2 with the low memory mysql, php5 and apache2 configurations shown under another tips and tricks section. Running out of memory in prefork mode would cause individual users to have dropped connections, running out of memory in threaded mode would cause many more connections to die.
A significant chunk of RAM can be saved by substituting apache2 for lighttpd and dropbear for sshd. I've succeeded in getting my server using a steady 39mb of RAM running lighttpd, mysql, php5 serving a wordpress blog.
I should note that the version of lighttpd currently available on the dapper repository is 1.4.11 which has a few bugs related to php5. I suggest that you install version 1.4.13 instead which is currently on the edgy repository but will require you to upgrade libc6 among others.
I did this by mapping out the dependencies by hand, downloading the .deb files with wget, and installing with dpkg --install. A slightly less painful method is to add edgy repositories to your sources.list and use the target release of 'edgy' when installing with apt-get. For example:apt-get install -t edgy lighttpd
Although libc6 is backwards compatible, occasionally some dapper packages list a particular version as required rather than minimum. It's recommended to install the edgy versions of those packages as well. If you checked up on all of the other dependencies and they're met, and you're comfortably sure that your dapper application will work with the edgy version of libc6, you can install it using dpkg --force-depends-version. That flag will turn fatal dependency errors into warnings.
it seems that the Ubuntu Edgy's lighttpd does not know about php5's cgi (lighty's fast-cgi script is dated). I was crashing lighty frequently in regular cgi mode but there is a way to run the arguably more reliable php5 in fast-cgi mode: first make sure you are disabling cgi and enabling fast cgi with
lighty-disable-mod cgi lighty-enable-mod fastcgi
you should make sure you arent enabling cgi or fastcgi in the main configuration file.. then in /etc/lighttpd/conf-available/10-fastcgi.conf change to the following:
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php5-fcgi.socket",
restart lighty with
/etc/init.d/lighttpd force-reloadI learned of this from: [1]
Please see the following guides:
Keep lighty lit! (in case it crashes): Monitor and restart Apache or lighttpd webserver when daemon is killed
HOWTO: Configure PHP with lighttpd using fastcgi
Copyright © 2009 VPSLink, a subsidiary of Spry
