Archive for category Linux
Because I am feeling accomplished, and because I also want to avoid my physics homework.
I think I’ve got a pretty good system working for CS137 (and the UW CS servers) now. I’ve got:
- sshag working, so I don’t have to eval `ssh-agent` && ssh-add each time I open a new screen session
- a modified version of the marmoset_sumbit script that now automatically adds a tag in git with the assignment & submission number when I submit an assignment through the command line
- bash actually working and running .bashrc when I login, instead of having to manually run it each time
Note: This is a personal VPN, so I just used static keys. A general guide to getting OpenVPN set up is available on the OpenVPN website, but this guide is targeted at CentOS 5 on an OpenVZ VPS.
This guide should be usable in other RH derivatives without much (any?) modification; and with slight modifications for debian-style distros, especially in installing packages and folder paths.
If you’re not running OpenVZ, I’d recommend following the site where the vast majority of this guide comes from, but I had problems with it – I had to mess around with the config files, and the iptables commands *will* kill your SSH session if you run it. Read the rest of this entry »
Note to self: When configuring iptables, don’t copy + paste
/sbin/iptables -F /sbin/iptables -P INPUT DROP <bunch of other commands>
I had A Bad Time.
tl;dr – Either a plesk update or CentOS update borked an OpenSSHd install such that the sshd_config was pointing to an sftp-server that didn’t exist where it was looking for it, but existed in two other locations.
Fix was to update the sshd_config while investigating the possibility of removing the duplicate install. Read the rest of this entry »
I’m moving a VM from my own server to EC2. I’ve got $50 worth of credit from a Redhat event, so I would like to make use of that. (That, and my AWS account existed before the free tier was introduced, so I’m not eligible for that.) That said, I want to make that credit last as long as possible. There were two parts to this – resizing the EBS volumes so I don’t get dinged for more than I need.
Amazon says $0.10 per GB-month of provisioned storage – so I’d be paying ~80 cents/month for storage that I’m not using. Admittedly, it isn’t that much, but that’s where I looked first.
I’m in the middle of trialing EC2, and I’m using the official Fedora 17 images kindly provided by the community.
They make a great starting point, because I can then install my needed software.
Some of which, though, I consider absolutely crucial. So far, I’ve need to install vim, less, rsync and screen. I can forgive rsync and screen, and to a certain extent less… but vim?
Especially when things like NetworkManager, ModemManager and mobile-broadband-provider-info are taking up space. Then there’s stuff like plymouth – we’re not seeing a graphical boot screen, so I should be able to erase this, right?
Another thing from the xen-users mailing list:
Apparently the way to specify the dom0 RAM at boot in Xen has changed. You should now specify the maximum memory –
dom0_mem=2G,max:2G instead of
Also, a new addition to the Xen Best Practices suggests preventing Xen from auto-ballooning the dom0 memory down by changing
/etc/xen/xl.conf to 0.
While trying to diagnose a problem with my VMs (namely, why starting a fedora 16 based vm fails to bring up the network connection), I ran into a strange issue – on my dom0 and some of the domUs, logrotate hasn’t been running, leaving me with insanely long logfiles!
So I set out trying to understand where the problem came from. Both the f16-based dom0 and domU had old logs, but my f14 domU was still working. That pointed to an update failing. And because logrotate never ran, I’ve got the yum logs of what was installed.
logrotate by default is setup to append the date to the filename, so I knew when logrotate was last run – 20111127. So anything between 27th November and 4th December could be the culprit. To start with, I looked at cron in particular, since that’s what supposed to run logrotate.
When I checked in my dom0, I got this:
[[email protected] log]# grep cron yum.log Dec 01 00:23:46 Updated: cronie-anacron-1.4.8-2.fc14.x86_64 Dec 01 00:23:48 Updated: cronie-1.4.8-2.fc14.x86_64 Dec 01 01:38:54 Updated: cronie-anacron-1.4.8-2.fc15.x86_64 Dec 01 01:38:56 Updated: cronie-1.4.8-2.fc15.x86_64 Dec 01 01:38:58 Updated: crontabs-1.11-2.20101115git.fc15.noarch Dec 01 03:05:41 Updated: cronie-anacron-1.4.8-10.fc16.x86_64 Dec 01 03:05:43 Updated: cronie-1.4.8-10.fc16.x86_64
Which showed me that I upgraded my dom0 to f16 on December 1st. Which is kinda helpful – I did upgrade cronie and cronie-anacron. Also, crontabs was upgraded, but only in F15. Then I looked at my domU. Again, judging from the dates in /var/log, I was looking for something between November 7 – 13. And lo and behold, I found lines that looked exactly like those in my dom0:
[[email protected] log]# grep cron yum.log Aug 20 15:20:05 Updated: cronie-1.4.8-2.fc14.x86_64 Aug 20 15:20:05 Updated: cronie-anacron-1.4.8-2.fc14.x86_64 Nov 07 18:33:50 Updated: cronie-anacron-1.4.8-2.fc15.x86_64 Nov 07 18:33:54 Updated: cronie-1.4.8-2.fc15.x86_64 Nov 07 18:33:54 Updated: crontabs-1.11-2.20101115git.fc15.noarch Nov 07 20:50:42 Updated: cronie-anacron-1.4.8-10.fc16.x86_64 Nov 07 20:50:44 Updated: cronie-1.4.8-10.fc16.x86_64
Except the F14 update was done in August, before the problem started. So, hmm, maybe the upgrade to Fedora 15 broke it. It would certainly explain why the F14 domU is still working fine. And I just happened to have an F15 domU that I had yet to upgrade to F16.
But it was strange – when I checked it, logrotate was working fine. /var/log had stuff timestamped 20120429, so the upgrade to F15 couldn’t have been the problem. logrotate kept an old version of yum.log, so I was able to look for cron related entries:
[[email protected] log]# grep cron yum.log* yum.log:Apr 19 13:16:38 Updated: cronie-anacron-1.4.8-4.fc15.x86_64 yum.log:Apr 19 13:16:40 Updated: cronie-1.4.8-4.fc15.x86_64 yum.log-20120101:Sep 12 18:54:29 Updated: cronie-anacron-1.4.8-2.fc15.x86_64 yum.log-20120101:Sep 12 18:54:30 Updated: cronie-1.4.8-2.fc15.x86_64
Which wasn’t very helpful – I was using virtually the exact same versions that I had upgraded my F16 systems to – 1.4.2. So it wasn’t the F14 -> F15 upgrade. So maybe it was the F15 -> F16 upgrade?
I puzzled over this, then I saw a log named ‘cron’. Which turned out to really be key:
[[email protected] log]# tail -n 5 cron
Dec 1 01:39:01 elemental crond: (*system*) RELOAD (/etc/cron.d/0hourly)
Dec 1 01:41:01 elemental crond: (*system*) RELOAD (/etc/cron.d/smolt)
Dec 1 01:43:01 elemental crond: (*system*) RELOAD (/etc/cron.d/sysstat)
May 1 23:49:29 elemental crontab: (root) BEGIN EDIT (root)
May 1 23:49:41 elemental crontab: (root) END EDIT (root)
The crontab made sense – I run crontab -e to see if logrotate was in root’s crontab (which it wasn’t), but the crond entries were interesting – for one, it showed me the exact time it stopped, but also told me that cron has a daemon. And guess what was part of the F15 -> F16 upgrade? Moving stuff to the new systemd.
So I quickly checked crond’s status on a F16 machine:
[[email protected] log]# systemctl status crond.service crond.service - Command Scheduler Loaded: loaded (/lib/systemd/system/crond.service; disabled) Active: inactive (dead) CGroup: name=systemd:/system/crond.service
Which, oops, that looks bad. But the F15 machine looked a lot better:
[[email protected] log]# systemctl status crond.service crond.service - Command Scheduler Loaded: loaded (/lib/systemd/system/crond.service) Active: active (running) since Mon, 30 Apr 2012 14:16:01 +0800; 1 day and 10h ago Main PID: 831 (crond) CGroup: name=systemd:/system/crond.service â 831 /usr/sbin/crond -n
And finally the F14 machine looked like this:
[[email protected] init.d]# service crond status crond (pid 1118) is running...
So it seems the fix is to enable crond. I have no clue why crond would be disabled between F15 -> F16 upgrades, but I’m seeing it on two different F16 systems, both of which were upgraded from F15. I might do a clean install of F16 and look, as well as try an F15 -> F16 upgrade, but that’s for later.
For now, I’m doing a
systemctl enable crond.service followed by
systemctl start crond.service on the three F16 systems and calling it a day.
Before I upgraded my dom0 to Fedora 16 (and by association Grub2), I had the dom0 memory limit fixed as an argument in grub.conf. When I upgraded to Grub2, I initially added it manually to the Xen boot command line, but eventually stopped doing that.
Today while looking through the xen-users list, I found an email that mentioned how to get grub2-mkconfig to automatically add it for you – add GRUB_CMDLINE_XEN=”dom0_mem=1024M” to /etc/default/grub. It seems to be the same on both Debian and Fedora, so I don’t see why it wouldn’t work on dom0s built with other distros.
So, I’ve wiped my test system with the intention of doing a tutorial on installing F16 + Xen. As part of this, I looked into installing a F16 domU with virt-install. When I tried it previously, I ran into this bug, and I ended up having to vnc into the dom0 and use virt-viewer to do the install.
Recently, there was some activity on the bug, centering around using “
rd_NO_PLYMOUTH” to bypass the plymouth boot screen (the progress bar that scrolls across the screen, apparently – though why it’s in the installer I have no clue).
In any case, it seems to work – my revised install command of
virt-install -p -r 1024 -n rawhide -f /dev/domU/rawhide -l http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/16/Fedora/x86_64/os/ -x "ks=\"http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide\" rd_NO_PLYMOUTH serial" seems to do the trick – it gets into the console, at the very least.
That said, I get a nasty error using the partitioning scheme in my Kickstart file – grub2 wants a BIOS boot partition, a 1MB partition for storing files, and installation fails.
So, either I add the extra partition to the kickstart partitioning stanza, or I pass the installer an extra
nogpt option when installing.
Guess which I chose. The BIOS boot partition makes no sense for Xen, because we’re booting with pygrub – we only care about grub.cfg, not what GRUB files are present or even if the bootloader is installed (which leads me to a question – can we get away with not specifying a bootloader to be installed in anaconda? I imagine not, since that probably means grub2 won’t be installed, but it might be something to look into.)
Though, it does seem to have completely fallen over – pygrub’s not returning any data on a (F14) Xen 4.0.2 system. xm create rawhide.cfg just returns an unhelpful “Error: Boot loader didn’t return any data!”, but trying pygrub directly gives a bit more detail – “RuntimeError: couldn’t find bootloader config file in the image provided.”
Trying with my F16 testbed now…
Also, apparently, radeontool, yum-pluginfastestmirror & ntpdate aren’t present in the F16 repos, so I have to remove them from my Kickstart file.