Browsing through the top500 supercomputers list, I noticed that in the OS listing, 5 supercomputers are running specifically CentOS (1%) while 389 are running some sort of Linux (not specified).

From the Linux list undoubtedly more are using CentOS, but the remarkable fact is that this known 1% CentOS is the same amount as the 5 Windows supercomputers.

So if we assume from the 389 Linux supercomputers, more are using CentOS, CentOS outnumbers Windows for supercomputers. We simply don't know by what factor.

If only more organisations would be more specific to what exactly they are running.

View original post|Add to del.icio.us | Share

It’s a given that the world population is growing. It’s also a given that the world economy is currently slowing.  This overall slowing of the economy is triggering job cuts across many levels of industry, and IT is at the heart of many such trimmings. When IT itself is not being cut, the IT professionals are often tasked with finding ways to make things more efficient or to automate various processes so that other positions can be cut. Just how deep should these cuts go, and should IT professionals get any say in the matter? A speaker from Cisco once said that Linux was the lens through which he found the flaws in his networks.  I believe this metaphor can be carried further, and that IT as a whole exposes more about humanity than we realize.  With this in mind, just how far should we carry our automation endeavors?

Is it acceptable to script system management such that 3 admins are needed instead of 4? Should we automate a line of factory jobs to save the company some money, or increase shareholder profits?  Is making a product cheaper an acceptable reason to eliminate jobs?

How much responsibility does IT have in these actions, and how much responsibility should we take for them? Should we seek out ways to trim down the company and take a ’survival of the fittest’ mentality, or do we seek out a way to preserve the jobs of those around us? Should we question the corporate officers who direct the action, or is our job simply to follow orders and let the company’s leadership decide what’s best?

From automotive plants and wall street offices to the California budget there are examples on both sides of the issue. Where do you stand, and do your actions correspond to your beliefs? I’m genuinely interested in how people feel about this one, so please take a moment and let me know what you think.

View original post|Add to del.icio.us | Share

Dateline: U.S. Department of Labor
The largest increases in initial claims for the week ending Nov. 1 were in Ohio (+3,885), Michigan (+2,619), Pennsylvania (+2,155), Wisconsin(+2,119) ...
-- UNEMPLOYMENT INSURANCE WEEKLY CLAIMS REPORT (week ending Nov. 8 2008)
A friend wrote:
All this proves is that when someone crosses a state line to register to vote it is just as easy to register for unemployment while you're at it.
I think it is probably much worse than that

It is easy enough for anyone to set up a (several!) new 'employers' and then walk away from them 8 weeks later with no individual financial responsibility for the 'tail' -- after all, we encourages formation of 'small business, the engine of economic growth' and barriers to entry should be small, right?

Unemployment benefits may be had at full rate for 6 months after 6 weeks employment at a given 'employer' if one is otherwise qualified; when an 'employer' goes out of business, the employees are eligible for benefits Several telephone poles in central Ohio had signs, with differing phone numbers, for what appeared to be short term 'jobs' working to elect Obama and 'make Change'. I snapped a picture with my mobile device, and will see if I can find it for the exact text; I recall thinking at the time:
-- Don't the 'employee candidates' KNOW they will be let go the day after the election
Now, I think the answer is:
-- Sure -- indeed they were TOLD by the recruiter at the other end of the phone, that this was a way to get rid of a pesky 'termination for cause' {disqualifying} black mark which was keeping them from what they were 'entitled to'
As the One won, and 'We can do it!' if the system is properly 'gamed', I think there will be no investigations after Jan 20 to 'connect the dots', and the Lame One will just snooze out his term. 'No law will prevent it'

And so the Republic was lost. "Meet the new boss; same as the old boss"

View original post|Add to del.icio.us | Share

I was interested in testing Spacewalk on CentOS 5.2 .. in fact it was on my (already too long) TODO list . So i followed the instructions from the Spacewalk Wiki but it failed during the yum process : “Public key for asm-1.5.3-1jpp.ep1.1.el5.2.noarch.rpm is not installed”

Hmm, i imported both EPEL and Spacewalk rpm signing keys so i had a look on the key used to sign that package : “asm-1.5.3-1jpp.ep1.1.el5.2.noarch.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#37017186)”

Hey, that’s the Red Hat security team signing key ! Why was it used to sign a package in the Spacewalk repo ? I guess that it’s imported by default on RHEL5 but you have of course to import it (and first verify it of course) : see the key 37017186 on the http://www.redhat.com/security/team/key/

And now the fun begins ..

View original post|Add to del.icio.us | Share

I might be the last person on this planet to join twitter, but sign up I have. And my username there is *drumroll* CentOS *drumroll*. And since people who read my blog might actually want to follow whats on there, here is a link to the feed CentOS on twitter.

First question though, how do I follow a search ? eg. I want to follow what everyone is saying about 'kung fu dancing' ? I hate to need to now *also* look at a rss reader to keep track of stuff on http://search.twitter.com/

- KB

Original post.

View original post|Add to del.icio.us | Share

Okay, I guess I covered too much too fast last time I discussed adding a signing key to RPM. Let's do it again with more annotation and color commentary.

The RPM package manager (see: the old RPM.ORG website, which I maintained as 'rpm.org' for several years; JBJ's 'way forward' for RPM development site; and the rather sparse, intentionally stale, and to me useless site controlled by and populated to suit the Red Hat corporate agenda -- details of the fork in RPM are out of scope here) has the capability to verify through strong cryptography that a package is intact, and is counter-signed by a person in possession both halves of an asymmetric public and private keypair. Assuming that reasonable care (where 'reasonable' is a very large and paranoid number) is used to protect the confidential nature of the private half, the chances of a successful substitution are vanishingly small.

Anyone can examine and inventory the keys in RPM's trusted keystore. The process of additions, changes, and deletions of keys is an operation requiring root level privileges, and so assuming a machine can be trusted (both network level and local physical level attacks need to be considered)

Enumerate the keys present:

$ rpm -qa gpg\*

Examine a specific key:

$ rpm -qi gpg-pubkey-e8562897-459f07a4

If we know or can determine the 'fingerprint' of the public half of a signing key, and if that key has been placed at a public keyserver, we can retrieve it, examine it, or even directly import it. For the sake of this example, we again consider the Raw Hide SRPM signing key (with the re-organizations over time, Red Hat presently signs Raw Hide content with key: 0x4F2A6FD2 which the MIT keyserver identifies thus)

The CGI query on the link above used the 'op=index' modifier; the next uses the 'op=get' -- one assumes 'op' is shorthand for the type of query operation made -- terse, or key-bearing. In any event, we retrieve the key into a local file thus:

$ wget -O fedora-key "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

and then may examine it with the conventional 'nix tools:

$ less fedora-key
<title>Public Key Server -- Get ``0x4F2A6FD2
''</title><p>
<h1>Public Key Server -- Get ``0x4F2A6FD2
''</h1><p>
<pre>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP Key Server 0.9.6

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJ
D11NUCqH8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwt
... snip ...
r/T7zLrJeiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iE4EGBEC
AAYFAj+dnTwAEgkQtEJp0E8qb9IHZUdQRwABAf/+AJwNVicN6A0I7EOfWx50PDHD
7SHw5wCfUJkeh/XlCrGdPASe/AXZB44jl2c=
=aXEw
-----END PGP PUBLIC KEY BLOCK-----
</pre>

The important thing to notice, amid the HTML markup, is that the key is 'armoured text' well set off with start and end markers, so that GnuPG (and also RPM) may pick the key out of the chaff.

We discussed previously the chain of steps we used to decide that the key was authentic, and worthy of trust; as such we do not repeat them here.

Then, using the 'sudo' command to temporarily attain 'root' rights for the importation step, we can insert (import into the RPM database) the locally checked key:

$ sudo rpm -import fedora-key

Or, assuming that we will do a post-insertion check, we can do the import directly from the keyserver:

$ sudo rpm -import "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

Then we can re-inventory keys, and see the new one present, and the full name under which it may be found; part of the name is, conveniently, the 'fingerprint' of that key.

$ rpm -qa gpg\*
$ rpm -qi gpg-pubkey-4f2a6fd2-3fcdf8c9

Hopefully this clears things up a bit.

View original post|Add to del.icio.us | Share

While most shops keep their nagios installs protected, folks with a publicly available nagios instance should update as soon as possible. There’s an interesting pair of security vulnerabilities which admins should be aware of. The first allows for users to submit commands to cmd.cgi that they would not ordinarily have permission to submit. This is basically a priviledge escalation issue and its severity depends on who has access to your nagios instance, and just how disgruntled they are.

The second is the more serious of the issues, and was described best by Andreas Ericsson, a major nagios contributor.  Quoting from Andreas:

Nagios CGI's are vulnerable to a Cross Site Request Forgery attack (csrf). A CSRF attack requires a couple of things for it to work, and it relies on the webs abilities (or rather, the browser's abilities) of posting form-data to a site which is other than that of the site presenting the form. Here's how it works: Unsuspecting Nagios Admin (UNA from now on) logs on to the Nagios server and checks the status of his/her network. Since everything's ok, UNA decides to leisurely browse evilsite.com, controlled by Dr Evil. On evilsite.com, there's a page containing a bog-standard web form, but with some hidden variables and an 'action' tag that points to UNA's cmd.cgi on UNA's Nagios server. When UNA submits the form, Dr Evil has all of a sudden sent data of his/her choice to the responding page on UNA's site. It's important to note that UNA's browser is being used, as it leads to a couple of interesting things: * UNA sees the output from cmd.cgi. It's never sent to evilsite.com, which can only guess if the attack was successful or not. * Firewalls can not be used to defend against this, as UNA requires access to the Nagios server in order to work. * Cookies can't be used either, as they are helpfully sent to the Nagios server whenever the browser loads a page from it. Why is this bad, then? Well, it's not so evil in itself, and the most horrible thing that it should have lead to was Dr Evil being able to enable / disable notifications or stuff like that, but in Nagios 3 we gained the ability to change checkcommand arguments and suchlike, which, combined with the csrf above, ultimately led to Dr Evil being able to run any command of his/her (who says girl's can't be evil?) choice on UNA's preacious Nagios server as the Nagios user. So what's the remedy? Well, a proper remedy is to implement in-form session tokens, which makes sure that the form submitted by the user came from the site we would like it to have come from (namely our humble selves). I'm working on that right now, and hope to have it done by this afternoon. It's been loads of fun implementing that in super-paranoid C, by the way. In the mean-time, we've blocked use of the CHANGE_ commands from the CGI's, and also made sure that multiple commands can't be submitted as one (fe by using comments with newlines). This interim remedy brings the worst-case scenario down from remote command execution to a more prank-like level (acknowledging problems, adding or deleting comments, etc, etc). A couple of things to note: * Information disclosure is not possible. No remote user can see anything from your authentication-protected Nagios servers. * Invalid commands read from the FIFO are always dropped flat by Nagios. * Since commands must be valid, it's not very easy to submit a command that has all the information required. Social engineering is required. * You *will* notice if this happens to you, since you all of a sudden will end up with cmd.cgi (not in a frame either) saying "Command submitted successfully" or some such.

For the full details of this,  you can follow the thread here.  Mostly, If you’re currently using nagios 3, you should update.

View original post|Add to del.icio.us | Share

They paved paradise and put up a parkin' lot
With a pink hotel, a boutique, and a swingin' hot spot
Don't it always seem to go
That you don't know what you got till it's gone
They paved paradise and put up a parkin' lot

-- Joni MitchellI flew into Phoenix for a week's rest, and was unpleasantly confronted with America West USAir's 15 dollar baggage check flying in. Took the SuperShuttle up to Scottsdale, and had a driver on his third day on the job for them. We were seeing part of the Valley new to him, anyway.

He drove a route up Scottsdale past the site of the former Raw Hide Western Town and Steakhouse. It has been gone three years now. The old site was bull-dozed flat, but it looks as though the developer who started condo construction ran out of money half-way through the project.

Dinner early in the week up in Carefree was to be at Crazy Ed's 'Satisfied Frog' -- its menu has the old saw about how 'it is so popular, no-one goes there anymore'. Last time, we ate at 'The Horny Toad' (as I recall Ed lost the Toad in a divorce; his ex kept running the place). Drove in from the west after a visit to Fry's Electronics on Thunderbird. Gone -- an imposter with new signage in its place -- google says I missed the close by a month.

Drove up to Page AZ for a wonderful nature hike in a private 'slot canyon' with Overland Canyon Tours and photo session [highly recommended and well worth the premium price]; on the way back decided to stop in Sedona for a nice dinner, and found that the high end restaurant we dined at a year ago May had closed doors; at least there is a new bank branch in its place.

Oh yes -- and two traffic circles -- a new concept there; their City Engineer must have heard how great they are -- on State Route 89 inside the city limits, and another four or five on the way back toward I-17 south of town. As traffic circles are a foreign concept, each cardinal entry point had illuminated, gas generator powered signage explaining their use. The fumes and noise are only remporary, right?

Well, it's the last night in town, and so we decided to go to Pinnacle Peak Patio; the resturant may have opened to the public in 1957 (per its website last updated 2007), but their display cabinets show postcards and envelopes from WWII simply addressed to 'John Doe; Pinacle Peak; Phoenix'. The waitress, proud of her new leather belt, and 'new in town' still bearing a California accent, came to the table. Once we indicated we had been eating there for nearly 20 years, she blurted out that the place is 'to close next March, or mebbe a year later as the developer "gave an extension"' before it is to be knocked down for yet another 'resort community' near Troon. She had heard about those other places, 'though. Seeing my reaction, she offered that 'perhaps they'll rebuild inside the new facility, but it will probably look like all the other chain restaurants'. Yeah, probably.

Well, at least a pack of coyotes woke me up at 2 in the morning, midweek, delighting at the moon; the red rocks watched silently as they have forever, and with any luck will continue to do.

View original post|Add to del.icio.us | Share

(full size)

When the Nazis came for the communists,
I remained silent;
I was not a communist.

When they locked up the social democrats,
I remained silent;
I was not a social democrat.

When they came for the trade unionists,
I did not speak out;
I was not a trade unionist.

When they came for the Jews,
I remained silent;
I was not a Jew.

When they came for me,
there was no one left to speak out.
-- Pastor Martin Niemöller (1892–1984)

We had a truck strike the power pole for the building hit last week; it took out the transformer with a most satisfying 'pop'. It also had the secondary effect of a power surge, which caused a 'fried' monitor, so that I had occasion to need a new one to get us back up to full complement.

New monitors offer an occasion to play 'monkey move up,' it is my turn for the upgrade, and the $200 price point has a nice Westinghouse L2210NW panel display [1680 x 1050 pixels, 22" diagonal] at the moment. I have had a Westinghouse LTV 19W3 [1440 x 1050, 19"] which I have enjoyed using since January 2006, and it seemed to make sense to stay in the brand. (I bought the 3 year service plan on that one for an extra 25% on the price, as I was unsure as to durability of this, by first panel, but that has never been needed)

One trial and tribulation (and geeky challenge) of a new resolution is the need to adjust the video card driver to support the new Modeline, and to squeeze every ounce of performance out of the monitor. I am an old hand with the Intel Modeline tool, 810resolution, and its successor, 915resolution, for my present X desktop chassis' video card.

Over time, 'progress' has removed the tools for a 'nix admin to configure a display for the X window manager:

• Xconfigurator
• xf86setup
• a working X -configure
• kudzu
• system-configure-display
• manual configuration of /etc/X11/xorg.conf

I find that the new panel has consumed 6 hours of setup time at this point, and is still not working, edge to edge at full resolution. Unpleasantly I was surprised to find kudzu erroring and dying; ddcprobe --raw returns nothing; X -configure and system-config-display seem to know only how to turn the screen blank and lock up the keyboard so that a power cycle is needed to regain the unit (I'll write more on this later); and manual edits of xorg.conf have so far succeeded in getting only an off center, mis-sized image up.

This is not at the magnitude of the atrocities of which Niemöller wrote so well; I see the battle raging about making a gratuitous change to VT's over on the Fedora-devel mailing list with false statistics abounding, and the usual 'don't bother us with the facts, kid; our mind is made up' on knowing what you need and want.

Dax Kelson wrote well with diagnosis and action plan, but it seems to have fallen on deaf ears; 'pearls before swine', and 'the tragedy of the commons' again. We must fight the good fight anyway for"The punishment of wise men who refuse to take part in the affairs of government is to live under the government of unwise men"

-- Plato

Summary, for those still listening: I want fallback (and degraded but partial performance) modes when a tool is not working as determined by the person looking at it; I want diversity rather than monoculture in tools; I want a upstream community which does not 'break expectation' by 'feeping creaturism' (or 'creeping featurism').

I'll take a stroll to Stauf's (the coffee shop down the street) to lower my blood pressure.

View original post|Add to del.icio.us | Share

The CentOS community is pretty limited in what we can do to the core distribution. Since our mantra is "aiming to be 100% compatible with Red Hat Enterprise Linux" we cannot fix bugs or improve the CentOS core without waiting for Red Hat to make those modifications first. We have limited leverage and a 6-month release cycle against us.

But that is not the complete truth, Red Hat usually has an internal, a vendor and a public beta period and everything that is found within that time-frame might get fixed before it is being shipped (and frozen) for the next 6 months.

Today RHEL 5.3 Beta was announced with a lot of interesting improvements.

So if we can improve the testing during the RHEL Beta program, everyone in the CentOS community directly benefits from that as well. Therefor it makes a lot of sense to encourage the large CentOS community to take part in the RHEL Beta program and help with improving the next CentOS releases. (You don't need my back patting, start already !)

If you are looking for the RHEL 5.3 Beta ISO images, go to Red Hat Network, log in, click on Download Software, expand the RHEL5 channel for your architecture and go to the Beta channel. There you can find the RHEL 5.3 Beta ISO images.

PS Feels like a déjà-vu ?

View original post|Add to del.icio.us | Share

James, Mukund and I will be at the CentOS booth at LinuxExpoLive from tomorrow ( 23rd Oct ) to Sat ( 25th Oct ). And from the looks of things Lance should be around as well. So if you are in the area, come drop in and say hi. Its always great meeting up.

Also, there are plans for drinks and perhaps a curry on Friday night, post show. So if you fancy that, we are going to meet up at the CentOS booth at 17:45pm and head off. Everyone is welcome to join in, should be a good evening.

- KB

Original post.

View original post|Add to del.icio.us | Share

For want of a nail the shoe was lost,
for want of a shoe the horse was lost,
for want of a horse the knight was lost,
for want of a knight the battle was lost.
So it was a kingdom was lost - all for want of a nail.It is sensible to assume that the 'black hat' side is just a smart as the 'defense', indeed that they read the open literature and mailing lists, and think about where unseen holes might remain. They share and collaborate, albeit covertly and imperfectly.

The end case of this train of thought is that using a 'security through obscurity' approach is simply to 'hide and hope', ostrich-like, that the counter-party chooses another target.

So we end up with the case for openly discussed and developed security. It may not be possible to 'wash the linen' publicly at first, but if a project does not provide a frank and open 'root cause analysis' and response to its clientele, when an exploit has occurred, one has to question why one should trust them prospectively.

Part of basic system administration is inventorying the hosts under management. Based on review of some found cracker scripts, it is clear that some scripts 'phone home' information about the target or compromised host. At first, generic drop box accounts might have been used for transport, but of course those have to be retrieved, or forward along information, and as such can be traced in some cases. Game over.

So methods to anonymously place, and retrieve content emerge on the 'cracker' side:

• encrypted IRC networks for command, control and transport;
  
• computer mediated one-time pads and drop boxes which enforce proper use and are provable secure (at pg. 5), see also Schneier on the topic [we differ from his assertion that OTP are: 'also pretty much useless. Because the key has to be as long as the message, it doesn't solve the security problem.' While correct so far as it goes, that objection merely clarifies the remaining problem to solve];
  
• strong asymmetric [public, private keypair] cryptography with DH key transfer can permit truly untraceable secure communication.

The three preceding forms of root level access are taken from the news.

• for convenience, backups are customarily not strongly keyed with one time keys -- backup processes are customarily scheduled to run in slack activity periods, and so run at night when no-one is there to provide the keying; automated hardware one time keying systems that meet FIPS 140-2 standards are hard to do properly and expensive when certified to NIST standard levels
  
• locking bolts to control chassis access (the 'Kensington cable' chassis frame slot), BIOS lockdown, and tamper switch audit are routinely left unused and unmonitored
• the 'minimal' case of 'cracker' compromise

Presently Red Hat derived distributions carry too much gratuitous 'plain-text treasure' for a person in possession of an unencrypted backup, or with unchecked physical access to hardware, or who has root level read access.

I am thinking here particularly of harvesting 'known_hosts' and residual 'known_hosts2' for cleartext 'next hop' targets. I have speculated on this vector in the past.

Quick test to play along: run:
sudo find / -name 'known_hosts*' -print 2> /dev/null | grep [s2]$
and then as a non-privileged user, cat a few files. For extra credit and extra heartburn, repeat the inventory thus:
sudo find / -type d -name '*gnupg' -print 2> /dev/null

I certainly do not like what I see on my systems in reviewing the contents of the found files. It is clear that my practice (before authoring this piece) of rsyncing disk-to-disk backups around without cleaning up; and leaving working files on host transfers and migrations around are not well thought out as to security implication.

[herrold@centos-5 ~]$ wc /tmp/transferiso/1/root/.ssh/known_hosts
54 162 13967 /tmp/transferiso/1/root/.ssh/known_hosts
[herrold@centos-5 ~]$

Enough. I will not continue such a state of affairs. The default global ssh and sshd settings need to be altered in /etc/ssh/

man ssh_config provides:
HashKnownHosts
Indicates that ssh should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. The default is “no”. Note that hashing of names and addresses will not be retrospectively applied to existing known hosts files, but these may be manually hashed using ssh-keygen(1).and the tool for a system-wide cleanup and conversion is in the default open-ssh already:

man ssh-keygen contains the following option:-H Hash a known_hosts file. This replaces all hostnames and addresses with hashed representations within the specified file; the original content is moved to a file with a .old suffix. These hashes may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. This option will not modify existing hashed hostnames and is therefore safe to use on files that mix hashed and non-hashed names.
We just need to have the will and the time to make the changes, write the scripts, do the work to secure content, adopt better habits, and push those habits into scripted repetitive tasks. Yeah -- that's all ... hmmm

081023 typo, layout, and grammar fix

View original post|Add to del.icio.us | Share

Hi,

I am going to be at the CentOS booth at http://www.linuxexpo.org.uk/centos - come see us there. Also if you are based in the area and want to come help at the booth, we still need a few more people, and it would be quite appreciated!

The event runs from the 23th to the 25th Oct 2008.

- KB

Original post.

View original post|Add to del.icio.us | Share

"If I have seen further, it is by standing on the shoulders of giants."

-- Isaac Newton

Jon Postel
August 6, 1943 - October 16, 1998

Jon Postel served as editor of the RFC series from April 7, 1969 (its inception) until his death in Octover 1998. Full details of the debt we all have are outlined in the eulogy by Vint Cerf.

He died a decade ago, now -- we are poorer without him.

View original post|Add to del.icio.us | Share

Doc: "You see, Marty, this time I really, really know what I am doing, so you can trust me on this one"
Marty: "Gee, I dunno, Doc"

Fannie Mae Eases Credit To Aid Mortgage Lending - 30th September 1999 (New York Times)
... In moving, even tentatively, into this new area of lending, Fannie Mae is taking on significantly more risk, which may not pose any difficulties during flush economic times. But the government-subsidized corporation may run into trouble in an economic downturn, prompting a government rescue similar to that of the savings and loan industry in the 1980's.

Yeah ... but THAT will never happen again. That 'S and L bailout' thing was a once in a lifetime event. Six Sigma, and all that. We're smarter than that now. It's different this time.

View original post|Add to del.icio.us | Share

When I came home, I found a couple pieces of paper mail. One from Scottsdale AZ, and the other from Bologna Italy. Google Maps indicates a separation of 5,973 miles. Another source makes it a great circle distance of 5,981 miles.

Either way, they are each venue recently visited by family members, authorized to use my credit card.

It appears, also, that each venue has an efficient traffic citation issuance system, and I will have the privilege to dispute a citation for driving in excess of ten miles over the speed limit (Scottsdale), and for improperly parking a vehicle (Bologna).

At least it is late enough in the day for a single malt Scotch.

View original post|Add to del.icio.us | Share

I just released mrepo 0.8.6 with RHEL 4.7's RHN/up2date code included which makes mrepo work on other distributions without requiring to copy those libraries.

Some of the highlights include:

• Support for RHEL5 and CentOS-5.
• Added YaST Online Update support.
• Added fuseiso support (root access no longer needed).
• Added unionfs support to merge ISOs to a single tree.
• Faster relinking of repositories.
• Caching of directory indexes to prevent regenerating repositories.
• Proxy-support for rhnget and gensystemid.
• Added rhnget --list option for searching packages.
• Added rhnget --filter option for selecting downloads.
• Added rhnget --source option for downloading SRPMs from RHN.

See the ChangeLog for more details.

A big thank-you to the following list of people for helping out with features and bugfixes in this release:

• Ian Forde
• Gareth Armstrong
• Oliver Falk
• Tom G. Christensen
• Francois Aucamp
• Bruno Cornec
• Frederic Pica
• Gabe Johnson
• Bjoern Engels
• Chandan Dutta Chowdhury
• Alexander Bergolth
• Nicole Hähnel
• Leo Eraly

Please let me know if you find any problems with this release as I plan to fix any outstanding issues quickly in a subsequent 0.8.7 release.

View original post|Add to del.icio.us | Share

Mr Dooley reads the paper:


08:52 Facing shortfall, Massachusetts inquires about a Federal loan - NY Times

NY Times reports the Massachusetts state treasurer has asked the federal government about lending the state money under the same favorable terms given to banks and investment firms during the financial crisis ...


Call me old fashioned, but wasn't this result perfectly predictable [to the Fed, to Treasure, and to the Joint Economic Committee], once starting down the 'moral hazard' path?

View original post|Add to del.icio.us | Share

We are setting up a modest sized VoIP server for use within CentOS. Something that we can connect to for meetings, chats etc. And I was thinking, how cool would it be if there was such a thing - for any open source project to use. Most stable projects tend to be more than 1 person these days, and most of them tend to be spread over a wide enough area that conventional pots based conf calls are both expensive and hard to get going ( not everyone has a phone service capable of running a conf call, for example ). Since a voip client is included in pretty much every linux distro these days ( or heck, any OS released in the last few years has multiple options on free / cheap voip clients ) being able to get onto a conf call with other project members for regular sync up's would be great.

We have started doing this within CentOS for some new projects and infrastructure work, and its fantastic. You save so much time when using voice, rather than IRC and it also allows you to do stuff like talk through a shared screen session or a shared VNC session to do real work in sync.

Something like voip.osuosl.org for example would be nice. My guess is that the biggest app for this would be the conf call facilities, and perhaps a few static extensions per project. I wonder what would be involved in setting this up. Bandwidth is hardly an issue these days. CPU and Drive performance isnt much of a consideration either. So whats the blocker ? is it that no one has thought of this before ? or is it that there might be too many hours required on the admin side of things to keep tabs on stuff ?

Btw, I did pass this idea past Jeff Sheltren ( http://sheltren.com/ ) who seemed quite keen and which is why my example has osuosl.org url in there.

- KB

Original post.

View original post|Add to del.icio.us | Share

The CentOS-4 ServerCD's have always been very popular since they allowed people to get a mostly mainstream server online from a 1 CD installer. And since they come with all the regular installer stuff included in the full CentOS-4 distro, all provisioning tools and methodologies still work out of the box.

However, I missed a few updates with 4.5 and 4.6 ServerCD's. Good news is that with 4.7 its back on track. Within the next few days we should have the 4.7 ServerCD i386 and x86_64 Released. Keep an eye on the centos-announce list ( http://lists.centos.org/ ) for exact details.

One thing that that is always worth keeping in mind - the x86_64 ServerCD is completely x86_64 only. It has no 32bit Compat packages at all. So if you need a clean x86_64 install, the ServerCD is a good place to start from. And since the yum repo's are setup to be identical to the normal distro, once the system is installed, yum will find all the packages you need.

- KB

Original post.

View original post|Add to del.icio.us | Share

RIMM, the maker of the popular 'Blackberry' smartphone, seems to have forgotten what we all have known for a long, long time. In recent models, they moved from a roller clickwheel at the right thumb position, to a set of 'up and down' buttons, or a trackball.

Less precise, and less capable: The clickwheel could be operated by touch alone; the new variants cannot.

Making matters worse, seemingly no-one at RIMM ever is in a environment where their hands pick up grime. This grime, of course, transfers to the trackball.

The trackball is not field cleanable; compare contra the 'remove and clean' capabilities of a computer mouse. I see: Broken BlackBerry Blues over at thestreet.com today.

Time to 'stock up' with a couple unlocked '8700's off ebay, in advance of the day I lose or damage my current device.

View original post|Add to del.icio.us | Share

RIMM, the maker of the popular 'Blackberry' smartphone, seems to have forgotten what we all have known for a long, long time. In recent models, they moved from a roller clickwheel at the right thumb position, to a set of 'up and down' buttons, or a trackball.

Less precise, and less capable: The clickwheel could be operated by touch alone; the new variants cannot.

Making matters worse, seemingly no-one at RIMM ever is in a environment where their hands pick up grime. This grime, of course, transfers to the trackball.

The trackball is not field cleanable; compare contra the 'remove and clean' capabilities of a computer mouse. I see: Broken BlackBerry Blues over at thestreet.com today.

Time to 'stock up' with a couple unlocked '8700's off ebay, in advance of the day I lose or damage my current device.

View original post|Add to del.icio.us | Share

A recent questioner in the CentOS forums complained about the decision to carry older versions of Unix network services, rather than the 'latest and greatest'.

That person said the package was:
> dead stable
as though it was a criticism. CentOS is not and will never be anything but boring, predictable, and dead stable.

The use case was:
> it will be used as an email server for a small business
without any rationale on why a later version is needed. Security matters are backported, as part of the CentOS upstream's approach on an Enterprise grade operating system. CentOS dutifully issues said updates after a quick trip of a SRPM through the build process (trade mark elidement, signing, and other validity checking; announcement), and sends it off to the 'updates' mirror network, for yum to find.

One goal of consulting for third party clients is to hold costs down and yet meet requirements. Anything more, and the consultant may be learning, but the client's best interest is not being served.

Either the client is being charged while the consultant 'plays', or if not being charged, their business is (unknowingly) being used as a 'crash test dummy' venue for such exploration. Not good.

Consider the 'bus test':

What happens when a bus sideswipes the consultant, who is then out of commission for a month during recovery? [I know of other formulations of the 'bus test', of a more gruesome nature, but they are not needed for this hypothetical ;) ]

By forking as little as possible, nothing bad happens to the client.

Seems like a win to me.

Now, where did my coffee cup disappear to?

View original post|Add to del.icio.us | Share

... pretty well describes the way I felt most of last week.

One of my children commented that I had 'racoon eyes' when they stopped by the house; I was collapsing on the couch after dinner, only to awaken after nightfall, and retire to bed.

Finally the weekend arrived, and I made up the sleep deficit a bit. Made a run to the liquor store as well. I was looking for Seagram's 7 Crown, a favorite Blended Canadian Whisky, for a tall, cool '7 and 7'

None to be found. The store had a 'special rebate coupon' on Canadian Club in the 1.75 L size, so I picked up that instead as a 'tide me over', and a Wild Turkey 101, my sentimental favorite for an 'on the rocks' drink.

The store does have Lagavulin 16 at a fairly reasonable price, but in taking inventory before my trip to the store, I have two pleasant 'straight up' choices, and three bottles of less appealing Scotch to work through first. Truth be known, those last three will probably be consigned to the kitchen for holiday 'Scotch ball' cookies.

... later ... that Canadian Club is drinkable, but not something I'll be buying over 7 Crown. At least there is that rebate.

View original post|Add to del.icio.us | Share

The CentOS development team is looking into another solution for the CentOS website and forums. But there is no real knowledge or experience about Drupal (especially for forums).

So this is a request to the CentOS or Drupal community for people that have experience with Drupal for forums to join the discussion and help with the requirement and question to see whether Drupal would be an option for the CentOS Infrastructure team.

If you are involved in both projects and want to see Drupal being used for CentOS, now is the time to assist in that :-)

Thanks in advance.

View original post|Add to del.icio.us | Share

I blogged some time ago about getting CentOS 5.1 installed on a dedicated server at Hetzner . Because the r8168 nic was not recognized, you had to remotely setup the box from another linux distro and with some preparation (including preparing a driver disk , etc ..)

I still receive questions about that from people not aware that actually CentOS 5.2 default kernel has the r8169 kmod that works on such chipset (have a look at the CentOS wiki page dedicated to that thread)  . And the other good news is that you don’t need to setup first another small distro on the server prior to run the CentOS setup … Indeed Hetzner has now CentOS 5.2 in their supported distro list .. cool

So don’t ask me how to do it now : it’s now working Out-Of-The-Box [TM] 

View original post|Add to del.icio.us | Share

As we speak I am pushing the new wxGTK updates to the repository. It was needed in order to have a truecrypt package, but also required a lot of rebuilds and updates of packages that depended on wxGTK.

The good news is that this may bring us a bit closer to compatibility with EPEL, the bad thing is that the audacity builds fail (old and new versions) so for the time being no audacity, or no wxGTK update...

I also tried building the new VLC media player (0.9.2) but it had issues of its own so I did a rebuild of VLC 0.8.6i until I can fix it.

Let me know if you have any issues other than the audacity one.

View original post|Add to del.icio.us | Share

… but not packaged yet ! .. reason is simple. If you don’t live in Belgium you’re probably not interested in this post .. but for people like me it is : i was looking at the official belgium federal government page about the belgium eid middleware and i saw that a newer version was available . Great . We worked with Dag to package the previous version (we had to patch it but that’s another story) and provide it as an rpm for EL4/EL5 in the RPMforge repository. But then the fun begins : in the previous version (up to 2.6.0) the linux version was provided only as source, which could be a pain to install/setup for the ‘lambda’ user but great for packager/maintainer.

But for a strange (and not explained) reason they decided to only deliver binaries now … Of course i don’t mind if the Belgian government would provide binaries but at least correctly built ! Quick and stupid example : they claim to provide the ‘package’ for both Debian , Fedora 9 and OpenSUSE11 but not as .deb nor .rpm ! .. and i’ll not talk about stupid install.sh that doesn’t even care about missing dependencies … !

I’m not blogging now against the guy who was asked to ‘package it’ to provide binaries for the newer version .. but against the people who decide to *NOT* deliver the sources anymore on the same page ! How can we now succesfully build the newer version and provide a good/tested/correctly built RPM for CentOS/RHEL 4 and 5 when sources are missing ?

Dear mr the eid middleware developer, if you decide to provide binaries, i wouldn’t even care about the fact that you package it correctly or not .. i promise .. but *at least* continue to give the source code so that people who packaged it for different distributions and in different formats (including .RPM like we did or .deb like Wouter is doing for Debian)

Dear mr webmaster : at least on the Linux page, don’t ask as the last step (step 4) to update Windows …

/me is now spamming their servicedesk to have an official answer ..

View original post|Add to del.icio.us | Share

I noticed that the fairly recent CentOS wiki download page does not end up in the top5 on Google when searching for "centos download" so why not reference the page here and see if that helps to seed Google and how fast ?

View original post|Add to del.icio.us | Share

I have been updating my proposal for the new CentOS wiki frontpage. The aim is to reduce the number of links a new visitor sees, so it is easier to remember later or memorize the structure of the wiki.

A wiki is essentially unstructured and it requires determination and effort to put structure into a wiki so people can remember the structure subconsciously. That is the hard part with wikis and the part I dislike most.

Since most users enter the wiki via a search engine like Google and advanced users would very likely use the Wiki search engine anyway, the frontpage is mostly used by new users.

That was the main motivation for me to add a very short description of what CentOS is on that very page. But is also the reason why my proposal would reduce the number of links. Even though a lot of people would be looking for the documentation, help or downloads, we would also like people to visit some other aspects of our project wiki. Or simply indicate that anyone can contribute or donate, we don't have many other opportunities than the frontpage for that.

I also changed the current frontpage slightly with the new info admonition that Alain Reguera Delgado provided, so it looks more fresh.

The next thing we need to do is refine the sub-pages. The download and documentation page obviously needs to be very specific and quick, but the pages that talk about promoting, contributing or donating would instead be verbose and friendly.

Also the About page is something we have to put some effort in to show who we are and how we are organized. There is still a lot of work to do, and if you have some ideas about the wiki you can help us as well. Join the centos-docs mailinglist to discuss and improve.

And finally we need to have a simple page that explains the benefits and weaknesses of CentOS so that people get honest and objective information and have sincere expectations.

For me that is key when promoting CentOS.

View original post|Add to del.icio.us | Share