Sun, 22 May 2005
Removing Plesk from Hostcentric Self Managed Hosting
There is a company called Hostcentric that offers
some pretty sick deals for dedicated hosting.
But as with anything,
there
is a catch. In my opinion, the biggest catch is their installation of a user friendly control panel for the
entire server called
Plesk. Plesk isn't so much
a control panel as a magical transformation of Linux into a propriatary "hosting platform". It takes over the whole
OS. In fact, Hostcentric
explictly
forbids altering the server in any way outside of installing some userland applications. The operative phrase
the the previous link is "as long as it's compatible with the current OS". One would think this would mean Fedora Core 1 but it doesn't. It means Plesk.
So what's an enterprising hacker to do about this? Well, remove Plesk of course! Easier said than done. Those
sw-soft guys really did a number on Fedora. What follows is the efforts of three people casually exploring the
guts of Plesk for three years and eventually, removing it. Know your enemy, right?
The core of Plesk lives in /usr/local/psa. The PSA stands for Plesk Server Admin. You'll find lots of things strewn about the filesystem with the letters 'psa' tacked onto them. When you look inside /usr/local/psa you'll find something similar to a common UNIX directory structure. That's their ticket, they recreated the parts of the "open" OS it sits on top of and put them in their own obscured location. Plesk does things like logging, database storage and maintaining state in this directory. The short list of what services are dominated is:
Since so many other things depend on this location existing, we'll wait until the very last step to remove it. The first step is to discover what services Plesk has directly modified. The easiest way to do this is with
rpm -qa | grep psa. This will show you all the RPM packages which have been taken over. Kind of a lot. qmail, the MTA has to go. As does the courier imapd and popd daemons. There's a bunch of stuff in /etc/xinetd.d/ that's Plesk-ified. If this isn't a production server it's safe to disable this for now.
I'm going to take this time, before you start hacking to emphasize DO NOT DO THIS ON A PRODUCTION SERVER! and of course the obligitory BACK UP YOUR DATA BEFORE PROCEEDING!. Like the Debian GNU/Linux login message, this mini-howto comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.. I hope I have made this clear enough...let's proceed.
If you have already picked around the Plesk GUI, you might have noticed some weirdnesses with how they define "domains" and "users". I still don't understand most of it but here's the gist. An "FTP User" is someone added to /etc/passwd with a shell of /bin/false and their web root is their home directory. A "Web User" is someone. I have no fucking idea. A "SSH User" Or remote login whatever, is someone who is also added to /etc/passwd with a shell of /bin/bash.
Outside of /usr/local/psa the second most dominated location is /etc/httpd. This is where all the Apache configs reside. While Plesk hasn't modified the Apache binary, they have ruled the config file structure and made it almost impossible to allow you to edit the file by hand. Double plus ungood. Another caveate, which was pretty amusing in retrospect (although not during the 8 fucking hours I spent figuring it out and fixing it) is that Plesk uses suexec for CGIs.
RTFM if you don't know what it is. These Hostcentric servers haven't modified the Apache binary so it's using /var/www as it's suexec document root (the default). Amusingly enough, Plesk is using a
different document root, making it
impossible to execute certian types of CGI programs. It requires recompiling Apache to change this variable and it's doesn't stick across upgrades. Great! suexec is great if you have a huge shared hosting business but anyone spending $59.99 a month for a server isn't doing that. And if you are, you're retarded, you will lose. Moral of the story, don't use suexec.
There's really no simple way around the Apache config part. You have to open up the files in a text editor and delete all the <VirtualHost> definitions you didn't create yourself. The ones you did, you have to save and then modify for your new configuration. This took me tons of trial and error.
DNS is a tricky problem. Most people
don't fully understand DNS or just don't have to think about it that much and don't care. Don't worry, I was one of them too and it took me a weekend to get it. Now I do and it's very simple.
BIND is overly complicated.
djbdns is not. Which one do you think Plesk uses? Why BIND, of course. This is actually kind of unexpected considering they are already using some DJB software, namely qmail. Whatever...If you are already publishing some domains from this box, you aren't fully screwed but it's going to be kind of difficult. You'll have to shut down your DNS server while you transition to djbdns. Fortunately, Mr. Bernstein provides
good documentation on transitioning from BIND to djbdns. Read it, do it, it'll work. This is a simple one to get out of the way and it'll last for the life of the server. Make sure you remove named from the system's boot order so it doesn't turn itself on across reboots. Once you have a stable tinydns/dnscache system you can uninstall BIND.
The last part of Plesk terribleness is MySQL. Fortunately it didn't do anything that bad to MySQL except use it for lots of state information and some user databases. If you already depend on databases created by the GUI,
dump them out of MySQL just to be safe.
Now you should have a very good idea of the depth of this project. The icing on the cake is that Hostcentric's agreement forbids you to update the OS. Fedora Core 1 is
quite old. The whole point of open source software is the freedom to update. My better judgement tells me the lawyers who wrote this agreement have never used a computer for anything more than typing email and surfing pr0n on the web so I can safely ignore them. Our business and theirs do not overlap. No probs. The first concrete step to a Plesk free life is installing
APT, the Advanced Packaging Tool, created by the wonderful
Debian GNU/Linux project and updating your RPM database.
After installing APT, follow the instructions and choose a mirror close to you. Run
apt-get update and make sure it runs without errors. Then run
apt-get dist-upgrade and see how horribly out of date your OS is. Scary, isn't it? Please say no to all of these upgrades, since one of them might be a kernel upgrade and you'll have to reboot. What you can do now, it run
/etc/init.d/psa stop, which will shut down Plesk, whatever that means. Now you are safe to refer to the output of that
rpm -qa | grep psa command and remove and replace the programs. I chose postfix to replace qmail-psa. Everything else I just replaced with their Fedora supplied counterparts. Once all the *-psa packages are removed, run
chkconfig --list and make sure the services you want are in the list and set to on for levels 2, 3, 4 and 5. If they are, run
apt-get dist-upgrade and say yes. You might get some GPG verification errors, which I couldn't get around even though I imported the public key from the Fedora project. I had to edit /etc/apt/apt.conf to disable GPG checking to get the upgrade to complete without errors.
You probably have a new kernel which you should reboot into. This is a pretty critical step, so make sure your bootloader is properly configured. My server was using grub. Verify that /boot/grub/menu.lst is pointing to the current kernel and that the kernel exists at that location. Make sure the default is to boot into that kernel. If you are using lilo, the same should apply. I'm scared of lilo so I'll leave that as an exercise for the reader if you are using that bootloader.
The final step is rebooting.
But wait! There's one last bit of sneakiness I got bit by. Run this
ls -l /sbin/reboot. Depending on your system, you might notice that it's linked to /sbin/halt ! This means if you type
reboot it'll actually shut down the system! Fuck! You can be safe and issue a
shutdown -r now command to properly reboot. If something goes wrong and the system doesn't come back online, you'll have to submit a reboot request to Hostcentric. They were actually pretty good at doing this, with a turn around of about 20 to 30 minutes for me and in both cases their reboot worked where mine didn't.
When your new system is rebooted and running, make sure the services you want are running with
netstat -ltunp and if they aren't, start them with the redhat-centric
service whatever start. If it comes up, use chkconfig to add it to the boot order for runlevels 2, 3, 4 and 5. To be safe you might want to do one last reboot to make sure everything you need comes up automatically. If it does, congratulations! You have a brand new Plesk free Fedora server. Stay tuned for a howto for upgrading to Fedora Core 2.
posted at: 18:09 | path:
/hacking |
permanent link to this entry
Mon, 16 May 2005
Critical Mass Radio Network mixer
The
Critical Mass Radio
Network is a great project. I do some work with
The August Sound Coalition
on the monthly segment. Since the RNC, CMRN has used some experimental
features of
Icecast to do a
syndicated broadcast, switching between many cities on the same live mp3
stream.
After I went to the particle/wave conference in Helsinki, I learned
about a project called
User Radio.
He uses
Pure Data to mix between
various audio files or streams on the Internet. I took his concept and
started working on a mixer for the monthly CMRN broadcast.
This is the
development copy. Please don't use it for
anything functional. In fact, don't use it for anything if you haven't
ever worked with PD cause it won't make any sense at all. Anyway,
here it is. You need to have the
~oggamp and ~oggcast objects, which you can get from Debian testing by
running
apt-get install pd-externals.
posted at: 23:39 | path:
/puredata |
permanent link to this entry
Thu, 12 May 2005
Installing Debian Sarge on a 4801 with a serial console
I just got two 4801 boards. One running m0n0wall, which is working great
already and the other for an embedded Linux project. After a full day
and a half of reading and trial and error I have Debian testing running
with an interactive serial console.
I realize there are other ways to do this but this way provides the most
interactive feedback and requires nothing more than the standard
debian-installer system. I'm writing this because there are a lot of
conflicting documents on the web on this subject. Here's the steps I
took:
Download the netboot.tar.gz archive from the debian-installer directory
of an official Debian mirror.
Follow the instructions for configuring debian-installer to PXE boot.
Download a modified pxelinux.0 bootloader, since the one in the Debian
archive isn't functional. I'll
reference the bug report I opened yesterday in case it eventually gets fixed.
Rename pxelinux.cfg.serial-9600 pxelinux.cfg. Currently this is placed
in /var/lib/tftpboot by default. Install minicom (or another terminal
program) and connect the 4801's serial port to a desktop with a null
modem cable. Set your terminal program to 19200 8n1. Turn on the 4801
and you should see the BIOS in your terminal. Press ctrl + p and type
'boot f0' to boot from the first network port.
If everything is configured correctly, you should now see a bunch of
random characters on your screen. Disconnect your terminal, reset it to
9600 8n1 and start it up again. You should see the debian-installer
screen or a bootloader prompt. You can now install Debian as normal.
When the installation is finished and it asks you to reboot, do that but
disconnect your terminal and set it back to 19200 8n1. Turn off the 4801
and pull out the CF card. Connect it to a desktop PC and mount it. You
now have to edit some files to get Grub, Linux and getty to send their
output to the serial port. This is
well documented.
Once all those configs are set to (make sure the speed is 19200 8n1) you
can safely umount the CF card, put it back in the 4801, turn it on and
Linux should boot as normal. Since CF cards have a finite life span,
this is not the best way for building up the OS. I haven't figured out
the best way yet...
posted at: 23:09 | path:
/hacking |
permanent link to this entry
