On Mon, 2006-12-25 at 12:07 +0000, Ross Golder wrote: > Olav Vitters wrote: > > Strangely, the load on label even with openldap is much less than it > > used to be on button. Maybe because of the incomplete config mentioned > > by ninja. > > > > Yep, LDAP was much slower on button because the slapd.conf 'loglevel' > had been left at a non-zero setting, so much of the load was slapd > passing a ton of debug-level stuff off to syslogd. These things happen, > I guess. > > >> We simply need to get the other machines upgraded ... migrating > >> everything to box and label because they are RHEL4 isn't sustainable. > > What are the alternatives? > > Short of getting more new servers to migrate stuff to, our only option > seems to be to upgrade the ones we've got. But, I recall there were > issues and reservations raised by a few people about upgrading the RHEL3 > boxes due to the potential disruption it might cause and problems > arranging physical access to the machine to do it etc etc. Since then, > our only option has been to use whatever server we have available that > meets the requirements at the time. No criticism of your actions was intended. It sounds like it was the right thing to do to keep things going and improving. But I wanted to point out the value of having the LDAP server on a system that doesn't have much else running on it. If LDAP goes down, the cluster won't be in good shape. > > Agreed; I do not want anything else on box. Further, even box does not > > meet the minimum requirements for Bugzilla 3.0. > > > > Moving everything to box and label because they are RHEL4 certainly > isn't sustainable. In fact I don't even think it's a good idea as even > RHEL4 is starting to get a bit 'old' now itself, so will probably start > to give us the same kind of dependency problems as RHEL3 has if/when we > try installing recent versions of certain types of software or upgrading > old ones. > > For example, in the case of 'guadec.org' which was hosted on window > (RHEL3). We considered moving it to label, but RHEL4's version of PHP > (4.3.9, released over 2yrs ago now and several major revisions behind > the latest recommended production version) wasn't recent enough to host > a recent/secure(!) version of Drupal anyway. Luckily, Danilo was kind > enough to allow us to host it on progress alongside his L10N pages. If > we only had the choice of RHEL3 or RHEL4 at the time, we'd have been > left wanting. I don't think upgrading everything to RHEL4 or moving any > more of our services to our RHEL4 boxes is necessarily a good long-term > plan anyway. The equation is inescapable that: - Good maintenance - Long support lifetimes are always tied to (reasonably) infrequent release times; Debian sarge may look appealing now, since it was released a couple months ago, but it will be stale soon enough. My position may be biased, but I don't see any advantage to jumping to another distribution. I think we should as possible upgrade the boxes to RHEL4 or, if we are willing to wait a bit more, to RHEL5. > So, what is the best way forward? Does someone have a more 'sustainable' > plan to offer? :) Well, getting fancy with the upgrade process (migrating services, etc.) to get zero downtime seems unlikely to happen, but I think we could basically survive a more brutal process where we get a Red Hat IT person on site upgrade the boxes and make sure they are accessible again via SSH; then we can fire-drill and get everything back working again. If people are OK with that, I'll look into when we can get that to happen ... or if people want to wait until RHEL5 is out (I don't know the date, I couldn't say the date if I did know it, but beta 2 was released last month) we could wait for that. Beyond that: - I'll do some more looking around to see what we can do to improve the sysadmin teams remote management capabilities for the GNOME servers. - I think we have to recognize that the price of having a stable base operating system is that at some points we'll have to run newer versions of certain packages than are part of the operating system. We have to figure out how we can do that in a sustainable fashion. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part