Plenty of people seem to have an issue with snmpd logging connection information for each poll on CentOS 5, like this:

Jul  1 09:50:04 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:59768
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:56329
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:42126
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:47950
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:36634
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:52677
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:44864
Jul  1 09:50:05 doghouse snmpd[4159]: Connection from UDP: [10.0.1.10]:54498

This isnt necessarily a bad thing, however if you want to turn that off, on a fully updated CentOS-5 machine you can change /etc/sysconfig/snmpd.options to something like this :

# snmpd command line options
OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid"

Thats about all there is to it. Also, the reason why one finds so many different ways or achieving the same thing on the internet, isn't because everyone is wrong. Its mostly since the -L options syntax and use has been changing over the last few years. And while I am sure there is a good reason for this change but the developers really should consider keeping some backward compatibility in place.

- KB

I've just had my first ever gpg signed spam email. Yes it is gpg signed, and its signed correctly with a key that seems to not be mentioned anywhere ( or atleast papa google does not know about it ). These guys are still getting better and wiser. Whats next ?

Going to see how this shapes up over the next few days before dropping my gpg-header -> whitelist rule :/

At work, my desktop machine is a dual opteron 250 machine built on a MS-9620 mother board ( http://www.msicomputer.com/product/p_spec.asp?model=K8N_Master2-FAR ) and in the last few months the machine has become really loud - source of this tracked back to the cpu coolers. There is another case fan ( as exhaust, at the back to the case ) which is very quiet, and turning it off seems to make no difference to the overall sound. The PSU also seems to be relatively quiet.

Anyway, the plan is to replace those CPU coolers with something quieter, and we got some Noctua coolers ( http://www.quietpc.com/gb-en-gbp/products/amdcooling/nh-do ). But, inspite of them saying that it will work with a Socket 940 based Mobo, these ones dont fit! the problem being that the MS9620 seems to have some sort of a custom bracket for the fans already on there, and there seems to be no 'usual' hinged/clip type mounting for the cpu coolers. Whereas the Noctua coolers only have that usual hinge/clip mounting. I've taken some pictures of mounting for the existing cpu coolers, you can see them here : http://www.karan.org/pics/ms9620/

Anyone know what replacement coolers I might be able to get for this MoBo ?

- KB

One new feature I really like in the upcoming Thunderbird 3 tree : thread summaries in the message view pane. Here is an example:

Click the image above for a full size view.

What makes it even more cool, is that since Thunderbird can already recognise and mark the quoted portion in followup replies, it conveniently ignores this quoted text in the summaries.

Running dstat normally gives you something like this :

# dstat --nocolor
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  3   0  97   0   0   0| 820k  456k|   0     0 | 800B  866B|1054   255 

And you can split the disk metrics up based on devices using something like this :

# dstat -D sda,sdb,total --nocolor
----total-cpu-usage---- --dsk/sda-- --dsk/sdb-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ: read  writ: read  writ| recv  send|  in   out | int   csw 
  1   1  97   0   0   0| 176k   77k:  30k  162k: 411k  478k|   0     0 |3608B 4005B|1447  1458 
 33   2  63   0   1   2|   0     0 :   0   216k:   0   432k|2470k 1611k|   0     0 |2915  6967 
 31   2  65   0   1   1|   0     0 :   0     0 :   0     0 |2210k 1338k|   0     0 |2866  6051 

But you can also get deeper level device names / nodes to measure - which is required in many cases if you have drivers for storage creating nodes further down the tree than /dev. Eg. I have a setup where there are four mysql instances running, each with its own dedicated storage :

# mount | grep srv
/dev/cciss/c0d1 on /var/lib/mysql/node1 type ext3 (rw)
/dev/cciss/c0d2 on /var/lib/mysql/node2 type ext3 (rw)
/dev/cciss/c0d3 on /var/lib/mysql/node3 type ext3 (rw)
/dev/cciss/c0d4 on /var/lib/mysql/node4 type ext3 (rw)
/dev/cciss/c0d5 on /srv/wal type ext3 (rw)

so in this case, to get dstat reporting working you need to mention just the component level, like this :

# dstat -D cciss/c0d1,cciss/c0d2,cciss/c0d3 --nocolor
----total-cpu-usage---- dsk/cciss/c dsk/cciss/c dsk/cciss/c -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ: read  writ: read  writ| recv  send|  in   out | int   csw 
  3   0  97   0   0   0| 209k   89k: 201k   86k: 204k   85k|   0     0 | 799B  865B|1055   256 
 90   1   8   1   0   0|3196k   68k: 764k    0 : 816k   24k|1067k 1650k|   0     0 |1999   609 
 95   1   3   1   0   0|2548k    0 :   0  4084k:2448k 5700k| 660k  791k|   0     0 |1611   571 
 96   1   2   1   0   0|2628k    0 : 808k    0 :1620k    0 | 352k  798k|   0     0 |1835  1605 

And you get the details, for each block device.

- KB

One issue that lots of people run into is when they want a list of all pacakges in the repositories that match their requirements. By default yum will only show you the 'newest' or the 'highest version'. So looking for kernel-devel does this:

[root@chamkaur ~]# yum list kernel-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * fasttrack: mirror.ukhost4u.com
 * extras: mirror.ukhost4u.com
 * updates: mirror.ukhost4u.com
 * base: mirror.ukhost4u.com
 * addons: mirror.ukhost4u.com
Installed Packages
kernel-devel.x86_64                2.6.18-8.1.10.el5                   installed
kernel-devel.x86_64                2.6.18-53.1.4.el5                   installed
kernel-devel.x86_64                2.6.18-92.1.10.el5                  installed
Available Packages
kernel-devel.x86_64                2.6.18-128.1.10.el5                 updates  

Thats all good, except we have :

[root@chamkaur ~]# uname -r
2.6.18-128.1.6.el5

So what we are looking for is kernel-devel that matches our running kernel. Now, one way to do this is to run 'yum list kernel-devel-2.6.18-128.1.6.el5'; and if its there, we can install it. However, yum also has option called '--showduplicates', which will list all matches, not only the latest. Trying yum with that option gives us:

[root@chamkaur ~]# yum --showduplicates list kernel-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * fasttrack: mirror.ukhost4u.com
 * extras: mirror.ukhost4u.com
 * updates: mirror.ukhost4u.com
 * base: mirror.ukhost4u.com
 * addons: mirror.ukhost4u.com
Installed Packages
kernel-devel.x86_64            2.6.18-8.1.10.el5                      installed 
kernel-devel.x86_64            2.6.18-53.1.4.el5                      installed 
kernel-devel.x86_64            2.6.18-92.1.10.el5                     installed 
Available Packages
kernel-devel.x86_64            2.6.18-53.1.19.el5.bz321111            c5-testing
kernel-devel.x86_64            2.6.18-92.1.1.el5.bz444759             c5-testing
kernel-devel.x86_64            2.6.18-92.1.6.el5.bz_pre53             c5-testing
kernel-devel.x86_64            2.6.18-128.el5                         base      
kernel-devel.x86_64            2.6.18-128.1.1.el5                     updates 
kernel-devel.x86_64            2.6.18-128.1.6.el5                     updates 
kernel-devel.x86_64            2.6.18-128.1.10.el5                    updates  

Which gives us all the various versions of kenel-devel visible to yum, in enabled repos for the machine. And we can then go ahead run 'yum install kernel-devel-`uname -r`; and know its going to pull in the right version. The --showduplicates is also a good way to check the history of a package during its release cycle. And this option should become a lot more useful when you have the vault repos enabled.

Want a quick and easy way to check what the Excludes policy on a machine is ? Run this :

wget -q http://centos.karan.org/check_excludes.py -O - | python

It should give you some nice clean output, listing each repository enabled on the machine, along with the exclude setup for that repo. Something like this :

main: []
centos-base - ['perl', 'rsync']
centos-updates - ['perl', 'rsync']

Remember that the "main:" section in yum is the global system/repowide configs - anything listed there would be excluded from all repositories.

I needed it, but its Seth who wrote this snippet of code.

People complained, quite rightly so, that a few of my posts on the blog were not really clear with the content being cut off from the right edge etc. So, I've just replaced the skin with something that is more fluid and should expand to the width of the browser. Hopefully this will resolve that issue.

Yes, I know its very orange. Might need to do something about that!

- KB

If you need to remove large amounts of data from a table ( specially when you need to remove *all* the data in a table), remember its faster to drop the table, and recreate it rather than doing a 'delete from tablename;'.

eg: this is against a postgresql db:

drop table rawdata;

Response time: 0m 2s 433ms  Total time: 0m 2s 433ms

CREATE TABLE "rawdata" ("ip" char(33), "sdate" varchar(20) NOT NULL,
 "key" varchar(100) NOT NULL,"country" varchar(2), "region" varchar(2),
  "city" varchar(40), "machine" int);

Response time: 0m 0s 337ms  Total time: 0m 0s 337ms

Whereas:

delete from rawdata;
200000000 row(s) affected

Response time: 0m 15s 353ms  Total time: 0m 15s 353ms

In some cases, where you want to drop most ( eg > 80% ) of the data in the table, its faster to select the data to be retained into a temp table, drop the original table and rebuild the temp table to the original name.

- KB

# rpm --qf "%{name}.%{arch}\n" -qp hpacucli-8.0-14.noarch.rpm
hpacucli.i386

# rpm -qpi hpacucli-8.0-14.noarch.rpm 
Name        : hpacucli                     Relocations: (not relocatable)
Version     : 8.0                               Vendor: HP Company
Release     : 14                            Build Date: Tue 05 Feb 2008 07:37:37 PM EST
Install Date: (not installed)               Build Host: localhost.localdomain
Group       : Applications/System           Source RPM: hpacucli-8.0-14.src.rpm
Size        : 12596699                         License: 2005 Hewlett-Packard Development Company, L.P.
Signature   : (none)
Summary     : HP Command Line Array Configuration Utility
Description :
The HP Command Line Array Configuration Utility is the disk
array configuration program for Array Controllers.

Fail!

Has anyone given though to doing mirror updates via a 'push' rather than a 'pull' mechanism ?

Basically, when new packages are available the machines that get updates would do a rsync to the machines down the order, pushing the updates out. It would allow us to get more updates, out faster and also not need to waste cpu and i/o on repeated rsyncs that dont need to be run. It would also make it a lot more viable to run rsyncs with a '-c' option always set.

Yes, we could/would/should still leave in place some mechanism for people to setup new mirrors and also to do pull based rsync's as and when they need.

Just something to think about at the moment, and comments would be very welcome.

- KB

My email server decided to go south a few minutes back - and the backup isnt setup to really run in full production mode, which means that I have limited access to emails till the server is back up.

So if you are expecting emails from me, or have emailed me something - patience, I will get back to you but it might be only after early morning on Thursday 23rd Apr.

- KB

I've been forced-offline the last two days, my ISP - bethere.co.uk seems to have had a problem in the SE london area, and that means no IP down the line for users.

Getting through to their customer services seems to be a challenge too - calling their special members hotine at 0808 101 3430 just results in a dropped call. No ringing, nothing to say lines are busy or anything, just a dropped call. After trying for about 30 min, I got through and guess what : their customer support people are only saying 'there is a problem, we dont know what the problem is and we dont know if and when its going to get resolved'.

One thing he did mention was that the status is being updated on the members website, so everyone should look there. It took me about 5 minutes to explain to the moron that getting to the website was a challenge if the isp is what was down. Where do they find these people ? Some eastern european guy sitting in what sounded like his kitchen with the blender on in the background.

I've now managed to get a dialup link mobilephone->mobilephone that I have in the DC to get into my servers if the main front link goes down - and at 4800bps its not the most usable link for much else - but I am able to get to the bethere website, and get into the members area. The funny thing is, they just seem to think the problem will get resolved in a few hours, then keep extending that time. It was at midday yesterday that the problem was expected to get resolved. Then it became evening, then late night, then early this morning, then just after two pm today, now its just before seven pm. Lets see when it really does get resolved.

Oh well, I guess thats the state of ISPs. And these guys are supposed to be one of the better ones. I wonder why competence is such an elusive trait in the business.

We are pleased to announce the immediate availability of CentOS-5.3 for the i386 and x86_64 Architectures.

CentOS-5.3 is based on the upstream release EL 5.3.0, and includes packages from all variants including Server and Client. All upstream repositories have been combined into one, to make it easier for end users to work with. And the option to further enable external repositories at install time is now available in the installer.

This is just an announcement email, not the release notes. The Release Notes for CentOS-5.3 can be found on-line at : http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3 and everyone is encouraged to look through them once. Also worth browsing through at the CentOS FAQ's at http://wiki.centos.org/FAQ

+++++++++++++++++++++++
ArtWork update:

CentOS-5.3 brings in a completely new artwork stack. A big thanks to Alain Reguera Delgado, Ralph Angenendt, Marcus Moeller and everyone on the Artwork SIG for bringing us the best, most comprehensive artwork set yet. Also a big thanks to all the translation teams for their contributions to the installer artwork.

+++++++++++++++++++++++
Contrib repos are back:

Given the widespread requests for user contributed packages directly being hosted within the centos repositories, the contribs repository is now back with CentOS-5.3. There are no packages yet, but over the next few weeks we hope to have a policy and process in place that allows users to submit and manage packages in the contrib repo.

+++++++++++++++++++++++
Upgrading from CentOS-5.2 ( or CentOS-5.0 / 5.1 ):

If you are already running CentOS-5.2 or an older CentOS-5 distro, all you need to do is update your machine via yum by running :

'yum update'

Running 'yum list updates' before doing the update is recommended, so you can get a list of packages that are going to be updated. To check you are indeed on CentOS-5.3, run : 'rpm -q centos-release' and that should return: 'centos-release-5-3.el5.centos.1'

+++++++++++++++++++++++
Upgrading from CentOS-2.1 or CentOS-3.x or CentOS-4.x:

The only recommended way to update from an earlier version of CentOS is to download and run a fresh install. In some cases, running the installer with the 'upgradeany' option might also achieve the desired results, however you are strongly recommended to look at the CentOS Wiki where hints and notes about potential upgrade paths from CentOS-4/3/2.1 to CentOS-5 are provided.

+++++++++++++++++++++++
Downloading CentOS-5.3 for new installs:

When possible, consider using torrents to run the downloads. Not only does it help the community and keeps mirrors from running up high bandwidth bills, in most case you will find its also the fastest means to download the distro. There are present over a thousand people already seeding CentOS-5.3 and its possible to get upto 100mbps downloads via
these torrents.

-- Via BitTorrent :
CD:
http://mirror.centos.org/centos/5.3/isos/i386/CentOS-5.3-i386-bin-1to6.torrent
http://mirror.centos.org/centos/5.3/isos/x86_64/CentOS-5.3-x86_64-bin-1to7.torrent

DVD:
http://mirror.centos.org/centos/5.3/isos/i386/CentOS-5.3-i386-bin-DVD.torrent
http://mirror.centos.org/centos/5.3/isos/x86_64/CentOS-5.3-x86_64-bin-DVD.torrent

-- Via direct download:
Due to bandwidth considerations the CentOS Project does not publish ISOS directly from our network machines. However direct downloads are available from external mirrors over http, ftp and rsync, and a geoip based list is available at http://isoredirect.centos.org/centos/5/isos/ to give you the best predictable match ( and only lists mirrors that are
updated already, so you dont need to waste time looking for a sync'd mirror )

Some mirrors also publish DVD images that can be downloaded directly. Refer to the mirrors list page at http://www.centos.org/mirrors for more details Mirrors that offer DVD's are clearly marked on the page.

sha1sum for these ISOS:

i386:
4b454d76d06daa0b1772115e9b95c9465a4cecb0 CentOS-5.3-i386-bin-1of6.iso
0da3292ea1d90639714a5e7d77812568bc01ec05 CentOS-5.3-i386-bin-2of6.iso
77e867eb736b58f31cdd25c4835643ab795979e2 CentOS-5.3-i386-bin-3of6.iso
949ee93440e736c8414fb8b571178970a31e6675 CentOS-5.3-i386-bin-4of6.iso
5eafdea33c18f623bb9299ae624b8c8a12132bfa CentOS-5.3-i386-bin-5of6.iso
90ae5387a38f8ec805d877cc5525ae8dedc7f810 CentOS-5.3-i386-bin-6of6.iso
b7f85a3a493e3051e50515ef881214929c88a5f3 CentOS-5.3-i386-bin-DVD.iso
a0c640ae0c68cc0d9558cf4f8855f24671b3dadb CentOS-5.3-i386-netinstall.iso

x86_64:
7327174dc0cbb6531bc0e2f26e24788251717e91 CentOS-5.3-x86_64-bin-1of7.iso
d060ed2826a4c212eebf5e3a825ce75e77cb44e0 CentOS-5.3-x86_64-bin-2of7.iso
a0b7471ec6b742c962cc06b69624b0746025005f CentOS-5.3-x86_64-bin-3of7.iso
fe4106322d6b08344e82df8904142664a8a82522 CentOS-5.3-x86_64-bin-4of7.iso
8cb5539fa4241bc5d23798a3e2721b2ebd3b18fe CentOS-5.3-x86_64-bin-5of7.iso
8a8f32888279f701e15162dec6f52b5f5fb5effc CentOS-5.3-x86_64-bin-6of7.iso
f053b05ea8576ea7d72116fa246f914086238ca9 CentOS-5.3-x86_64-bin-7of7.iso
f8ca12b4acc714f4e4a21f3f35af083952ab46e0 CentOS-5.3-x86_64-bin-DVD.iso
e971bd1677622708348b8a65264ec360a1cc0196 CentOS-5.3-x86_64-netinstall.iso

+++++++++++++++++++++++
Pending CentOS-5.3 Updates and src.rpm's

Updates have been issued from upstream since they released 5.3, a bulk of these updates are already released into CentOS-5.3 and are available immediately. All pending updates will be released within the next 48 hrs. To keep the initial release size smaller, the src.rpm's are also going to be slowly released into the mirrors over the next 48 hrs along with debuginfo packages.

+++++++++++++++++++++++
Release Notes:

The distro release notes are only available online at http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3 The release notes include important changelog info as well as notes about the installer and outcomes from test situations which the centos-qa team worked through. Its considered essential reading.

Upstream release notes are available in the NOTES/ directory of the install media. These include release specific technologies, new features in the distro and other misc infomation that can help you better utilise the distro.

+++++++++++++++++++++++
Getting Help:

The best place to start when looking for help with CentOS is at the wiki ( http://wiki.centos.org/GettingHelp ) which lists various options and communities who might be able to help. If you think there is a bug in the system, do report it at http://bugs.centos.org/ - but keep in mind that the bugs system is *not* a support mechanism.

Some Friendly URL's :
http://www.centos.org/
http://wiki.centos.org/
http://lists.centos.org/
http://bugs.centos.org/
irc://#centos@irc.freenode.net

+++++++++++++++++++++++
A big thanks to everyone who contributed, including the translation teams, the qa team, the CentOS Developers and all the users out there. I would also like to thank all the users for their patience and help!

Enjoy this release, tell all your friends about it too.

--
Karanbir Singh
CentOS Project { http://www.centos.org/ }
irc: z00dax, #centos@irc.freenode.net

The release is going to get pushed out by another 24 hrs or so, ETA is now Tuesday morning UTC.

Getting the internal centos mirror network has taken a bit longer than I'd originally planned for - a couple of donated machines that were previously used to 'bridge' slow network links have gone away, and thats meant most of the last 2 days were spent juggling rsync's to make sure things move in the right direction, at reasonable speeds. My estimate on data moved within *.centos.org in the last 2 days = 1.2 TiB. Its not a very large number, but consider this : no two machines within the centos network are actually hosted in the same facility.

There is a *lot* of scope for changes to make the process more efficient, but I think we'd best do that sort of re-engineering when there isnt a release waiting to go out.

- KB

Do not try this at home.

Just use 'sed' to change data stored inside a running mysql db. And it worked too. Saw the change data come through within a few seconds. Wonder what the internal mysql process did when it realised that data on the filesystem had changed from what it had in cache. Although there is a good chance that no such test exists inside mysql to start with.

Scary thing is, this whole process worked. Which also means, in case you havent caught on yet, is that its possible to change users passwords and change data stored on file off the command line. Not sure why this surprises me, considering myisam tables are just flat files on disk. Still. Something to think about.

Selinux would help here.

- KB

This via Graham:

If you havent seen the original Erlang movie, you need to!

- KB

This year, the CentOS Project is going to make a pitch for and hopefully get onto the Google Summer of Code process. And we need people to come work with us on managing the process, mentoring projects that get adopted and also help with infrastructure and be backups for other mentors.

If you are interested and have the time + inclination to help out: get onto the CentOS-GSOC list ( http://lists.centos.org/mailman/listinfo/centos-gsoc ) and send an email with a brief introduction on who you are, what you do with CentOS ( or where you use it and how ) and some details on what you would like to help with.

The whole effort is being coordinated by Bill Scheel, with plenty of contributions from the usual suspects. But he's the person most likely to be around answering questions and helping out with new people who join up. Marcus and Ralph are backing him up! So expect to see plenty of them around as well.

See you on the list. And do hurry, were sort of short on time!

- KB

Just a quick post to explain what the Rebuild/Verify/Match (r-v-m) routine is... Firstly, CentOS has 2 types of packages and rpms. The first is what goes into the main distro - and contains sources that are from 'upstream'. The second lot of packages are things we add on, people contribute and are hosted in Extras/, CentOSPlus/ and Contrib/ repositories. This second lot of packages dont actually make it into the distribution.

For packages that come down the line from upstream, they go through a fairly automated process and are built, processed and put into a queue. Once in the queue, they are pushed through a 'test-harness'. Which does some basic things, like make sure new packages are actually higher Version-Release than packages with the same name in the existing repo, make sure the packages are signed properly and that their multi-lib shared content matches etc. Usual regular stuff. An important thing to keep in mind here is that packages are built in the order they are seen publicly. If there are multiple packages on the same day, then build order is usually timestamp[1] driven.

This process works for updates.

When there is a new release to be done, things get a bit more interesting - specially for new packages that have never been released before. They might have been built more than once, and each time in an evolving buildroot. Contents of those buildroots are impossible to guess. So a new package, say XX released as XX-1.2.3-1.el5 might have been built inhouse, upstream, from 1.2.0 to 1.2.1, 1.2.2 and 1.2.3 but only the last one is released, and in some cases bundles of these packages have overlapping requirements. Hello cyclic deps. Sorting these out is a totally manual process, and can take a bit of time, as is easy to imagine. Another thing that needs to be done is to make sure that our entire tree matches upstream as much as possible. This is the r-v-m routine. Each rpm is checked against upstream's ( there are quite a few tests done ). and depending on outcome cycled back into the build queue or passed through as matched.

For every package that goes back, there is a process that guess's and tries to establish what the reason for fail was, and howto work around it - almost 90%[2] of the cases, its down to different versions of packages in the buildroots. And guessing what should be in there is almost all a manual process. Also, once there are some estimated lists in place - building specific repo's for each package's build run takes time, in many cases longer than the buildrun itself!

It should be called verify-rebuild-match, but when I wrote this script about 2 years back, there must have been a good reason to call it rebuild-verify-match, I just dont remember what that reason is anymore. Also, there are a few scripts around that do various things, but the process overall is mostly manual. Something to think about for when 5.4 comes around - or even 4.8, which is a few months away now.

btw, not all packages goto 100% Perfect match before being usable. eg mismatch in docs generated at buildtime from source due to text alignment is a classic case that Johnny and I have almost always ignored. Sometimes its down the ver of the doc render app, and is resolveable - but only if there is time and were not already running behind time :)

- KB

[1]- There are some very complex exceptions to this as well, but generally timestamp is the way its done.
[2]- I've not actually counted them, the 90% is just a way of saying : most of the time.

In late Jan we drove from Gurgaon ( New Delhi ) to Chandigarh, fairly early in the morning and the experience was amazing. The thing is - people have always driven quite mad on the GT road, but now with the roads getting so much better, that level of 'mad' is more like 110 to 120 Km/hr, and the experience is quite surreal. Given that visibility on the day was like 10 feet.

Its not the best quality, taken on a mobile phone. But you should get a good idea of the experience. Specially the bit about people overtaking off the wrong side and doing so aggressively enough that it was impossible for us to switch into the left lanes.

- KB

Hi guys,

Am back in town now, and slowly catching up with emails - trying to keep up with the current ones as they come in and also doing some backlog work, so if you hear from me in a random order, dont panic! I will get through and reply to all emails.

In the mean time, the 5.3 work is now back in full swing from my side and we should see package movement today for QA to start doing their thing. There were some confusing issues w.r.t the buildsystem which I was unable to clear with Tru before flying out and thats the direct and only reason he did not push the packages out. Completely my fault.

I might not be on irc much over the next few days, but thats only because things are in 'head down - focus on issues' mode at the moment, email remains the best way to get in touch.

Above all, thanks for the patience and the fantastic support that everyone has shown over the last few weeks. It means a lot to both of us.

- KB

So, upstream dropped 5.3 today! And look at the size of that kernel bugfix list. Over the next few weeks we will try and get the CentOS-5.3 release done as well, however I'd really like to ask people to understand that I am working upto getting married in a few weeks time, Johnny is off with medical issues, and Tru is going to be pressed looking after the mirror networks, doing updates for centos-3/4 and helping out with 5.3 as well. So go easy on us if timelines we set are not always met to the dot. We shall still be doing our best.

Also, this is a good time to pimp my twitter feed at http://www.twitter.com/CentOS : over the next few weeks I shall try and keep that as updated as possible with 5.3 related info.

Update Jan 22 : The first round of package builds are now done. We will start moving to next stage : get the centos-qa team active on the packages, start finalising artwork, kick off release notes stubs. Normally this process runs for a week or 10 days. Lets see if we can make it quicker this time around.

- KB

Its amazing how often this question gets asked. Often enough that I thought its worth blogging about. Anyway the short answer is - you dont really need any services running on the machine in order to boot it, login and be able to do things. You might need to start services on demand though, eg if you need a mysql server running, thats a service that needs running. However, its a good idea, imho, to have atleast these services enabled and running :

syslog
network
sshd


syslog: because its good to have logging on the machine, and network + sshd just to make sure you can get to the machine from a remote location, and you can run yum updates ( either local or remote ) with the network working.

If you are running with selinux, it might also be a good idea to have restorecond running, but look into some details, its not really *required* as such.

- KB

In case you didnt know already, the iPlayer now works with the PS3's built in web browser. Just fire up the webclient and point it at http://www.bbc.co.uk/iplayer and things just work. Interestingly the UI is very different to what people see on their computer. The normal one is here : http://www.bbc.co.uk/iplayer while the PS3 / Wii interface is here : http://www.bbc.co.uk/iplayer/bigscreen

Also, there is a iPlayer labs thing going on, take a look : http://www.bbc.co.uk/iplayer/labs

- KB

This is something that James pointed out to me a while back, makes for very interesting reading on the state of yum today and how its improved in performance within the 3.x.x release cycle. :

yum benchmarks

Also, worth keeping in mind is that I've been trying to keep up with the latest yum developments and pushing yum + yum-utils into the c5-testing repo after a bit of testing. And in a few hours time yum-3.2.19-X ( almost 3.2.20 it feels like ) along with yum-utils-1.1.16 should be available there. Please test those as much as you can, and let me know how you get on :: via pretty much any means ( but the centos-devel list hosted at http://lists.centos.org/ is the preferred means ).

- KB