Stuart Herbert | Gentoo

I’ve just done an upgrade of a web box from Apache 2.0.x to Apache 2.2.8, using Portage 2.1.4.4. Somehow, Apache got built after the modules (PHP, Subversion, etc etc) were upgraded - and not before. This left Apache completely unable to start, because the modules had been linked against Apache 2.0. Grrr.

Gentoo’s new Apache 2.2.8 default config also left behind the mod_ssl config file from Apache 2.0 (for some reason, instead of updating this file, Apache 2.2.8 comes with a mod_ssl file with a different name)

Also had problems with /usr/lib/apache2/logs not existing, and with Apache’s Listen directive being hidden away inside the default vhost, instead of in the main config file where it belongs.

All in all, took me a couple of hours to dig through everything and sort it out. It’s not like Gentoo’s Apache team to fsck things up as badly as this; I hope this isn’t a sign of things to come, or else I’ll fork these packages and maintain them myself.

I’ve revbumped the seeds-config/lamp-server-portage package this morning, to change some of the USE flags that it sets in package.use. Doing so made me realise that bumping all the package.* files under seeds-config/lamp-server-portage/files just for a one line change takes too much work.

Instead, I’ve switched the seeds-config/lamp-server-portage to hold the package.* files inside the ebuild itself. Bumping the ebuild is all that you have to do, whenever we need to change the settings.

This has made me look at support for package.use in profiles from a different angle. I’m still in favour of that feature, but I’m no longer so sure that making heavy use of it is right for the Seeds project.

If we change the contents of the profile (e.g., we change the USE flags listed in package.use), but we don’t give the profile a new name … then we’ve changed the behaviour of the profile itself. It’s not like changing a package, where a user gets to choose whether he wants the change or not (he chooses by upgrading to a later version of the package or not). Changing a profile means that we’re forcing a change on a user; the only way they can avoid the change is to avoid syncing, or by versioning their own tree.

In the back of my mind, I’m aware that one possible outcome from the Seeds project is that we might choose to build it against a slower-moving copy of the Gentoo package tree (i.e. the so-called ‘enterprise’ tree). (We’re not doing any work on this atm, btw, before anyone gets their knickers in a twist). If that happens, then the LAMP Server packages and profiles are likely to have a much longer shelf-life than your average Gentoo package. LAMP Server users (if we ever gain any ) will want to be able to roll out identical installs across their web farms. Reproducability (something that the wider Gentoo tree makes difficult) could become an important factor.

So, at the moment, when per-profile package.use comes along, I’m not sure whether or not to switch the seeds-config/lamp-server-portage package over using it or not. It’s going to require a bit more thought.

If we don’t switch, then that’ll probably force our hand, and make us have all the seed packages pin their deps down to exact versions of packages (e.g., explicitly require net-www/apache-2.2.3, instead of just net-www/apache).

The LAMP Server’s base-system will now pull in the network-tools package.

As with all the LAMP Server packages, I’m sure we’re missing a few tools that folks’d like to see included. Let me know what’s missing, and I’ll take a look at it.

http://ossec.net/

One of the things that we need in the LAMP Server seed is a host-based intrusion detection system. It’s not the sort of tool that I’ve played with before; it’s nice to get to learn something new for a change

One of the packages I’m evaluating is ossec-hids. I’ve put together a basic package for this in my overlay (layman -a stuart-server). If I decide to take on the responsibility of maintaining this package longer term, I’ll move it across to the main Portage tree.

Samhain is also on the list, as is rkhunter. Any other packages I should be looking at?

I’ve been through all of the packages that are currently in the Gentoo Seeds overlay, and added some really basic documentation about each of them to the wiki. Right now, the docs are as much a memory aide as anything else, but at least there’s something for each and every package.

I haven’t documented the profile yet, nor written anything up about the SEEDS_EXTRA USE_EXPAND. I’ll try and get that done as soon as possible; it’ll make it easier for other folks to contribute

I should really have spent the day unpacking (just back from a lovely holiday in the Malverns), but instead the suitcase is still sat in the front room downstairs; I’ve been busy making some more changes to the very experimental LAMP Server seed.

The first experimental version of the LAMP Server is starting to take shape. We now have an embryonic profile (seeds/lamp-server/release-1), which may or may not completely hose your box (you have been warned!) I’ve also added a few packages in seeds-extra/; hopefully they’re starting to demonstrate my thinking on how we could handle the “value-added” bits of seeds. All of the “value-added” bits are currently managed by an experimental SEEDS_EXTRA USE_EXPAND variable. I tried having them as normal USE flags first, but it’s much clearer what’s going on since switching to the USE_EXPAND. Thanks to Donnie for his explaination of how USE_EXPAND works.

I’ve written up some (incomplete) instructions on how to install the LAMP Server seed on an existing Gentoo box. The main steps that I know for sure are missing are instructions for adding init scripts to the default runlevel. If you find any more steps that are missing, please add a comment at the bottom of the instructions.

I’ve kicked off a discussion about what package the LAMP Server should choose for server monitoring. Myself, I normally deploy cacti, which is great for general graphing, but doesn’t support the whole ’service up/down’ type monitoring that you’d also get from (say) nagios.

The security side of things definitely needs a lot more work too. We need to pick a firewall package and an IDS for starters. I’ve picked denyhosts to handle SSH log monitoring; should we be using something else instead? I’d also like to develop a tenshi configuration for the LAMP Server; does anyone currently have a working tenshi config file that we could use as a starting point?

Also on my current TODO list is making sure Rails is really well supported. Last time I checked, we didn’t have mongrel in Portage; that needs packaging up. The LAMP Server seed currently uses Apache 2.2, specifically to make it much easier to support Rails/Mongrel. We’ll also need to look into updating the capistrano ebuild, and seeing what else is needed to make capistrano work well on a LAMP Server (Aled - expect me to camp at your desk with a notebook when I return to work )

The announcement for the Gentoo Seeds project made top article on this week’s LWN’s distro page. Go check it out

They also include a link to their article on Joe Barr’s recent article. Their article is brief, but I’d urge every Gentoo developer to make the time to read through the comments attached. It’s always useful to keep in mind how folks feel about what we do; it’s too easy for us to get wrapped up in our own little eco-system and forget the users themselves.

That’s why it’s also worth reading Slashdot’s more troll-like take on the Seeds project. There’s a couple of clear trends running through the comments attached to that posting. There’s also a cowardly attack on Seemant by someone claiming to be a Gentoo developer. If that really is from a Gentoo developer, well, all I can say is that just hope it’s not from anyone I call a friend, because I think that’s disgusting.

We’ve taken the idea of creating stage4 tarballs, and planted that seed as its very own project!

Gentoo Seeds is a new project, which will work on creating rich Gentoo installs for common scenarios. We’re starting off with a Gentoo LAMP Server, and are already talking about following that up with a Gentoo LAMP Developer Desktop.

We’re at the “let’s figure out how to do this” stage. If you want to join in, please do! We’re hanging out in #gentoo-php for the moment.

And we’d love to work with other Gentoo devs who have ideas for seeds of their own.