Slashdot Mirror
Ximian Testing Red Carpet Daemon
rainmanjag writes "GNOMEdesktop.org noted a new page on Ximian's site announcing the testing release of Red Carpet Daemon which would allow administrators to do automatic software updates on workstations within the enterprise. You can also get a command line copy of Red Carpet." Hopefully this works out better than the time I cronned apt-get upgrade under Debian's unstable tree. Whoops.
For the last eight months, we have been using autoupdate at our site to keep about 50 RedHat Linux boxes up-to-date. It seems to work pretty well. Though, this red carpet stuff looks pretty interesting too.
...under unstable and it has only let me down once or twice. Luckily it never hosed my machine beyond repair.
Slashdot's first reaction to VMware
Sounds like a clueless poster.
Northon ghost only solves the problem of -installing- the identically configured machines, not for maintaining them. I also would recommend to do scripted installs rather than using ghost. Ghost is a windowsism. We have much better scripting tools on Linux (including many tools specifically for system administration), we can do better than Ghost.
I'm not sure I'd trust Ximian to auto-update my system - while they try pretty hard, I've had just too many dependancy conflicts updating RPMS from them to feel really warm and fuzzy about having it happen automatically.
" should be uncerimoniously bounced from any stable release. That's one area I will give the Debian folks credit - they maintain their packages.
Also, one thing I like about RedHat's up2date vs. RedCarpet is that I can tell up2date to leave my damn X server alone!. Neither RedHat 7.2 nor Ximian have XFree 4.2, but at least I can tell up2date "hands off any package with XFree in the title" and not worry about it downgrading me to 4.1. Every time I run RedCarpet I have to tell it "No, I DON'T want you updating my X server, yes I know this is a "security release", but I don't need it!"
Unless redcarpetd has the ability to prevent upgrades on selected packages I wouldn't trust it.
And until the packages get vetted better for conflicts I would be careful. That's what ALL RPM based distro's need - a standard base of packages and libraries that released packages are not allowed to deviate from. Any RPM that call for "foo-1.4.2-unreleased-unstable-pl1.4-thursday.rpm
www.eFax.com are spammers
Sounds like a clueless poster.
No, not at all. This is a very genuine concern. Personally, I think having a separate daemon to do this job is a very dumb idea. Existing, well tested tools like ssh and cron could do this, and the less new, untested code that runs on the network, the better for security.
For a start, it's going to have a port open on the network in order for a master computer to contact it and tell it to update. This in itself is a major security risk - any open port is. Now also remember that, because it will be updating packages system-wide, part of the update process is going to have to run as root - I hope at least the network-facing daemon doesn't. If it does - instant remote root when the first stack-smashing or format string exploit comes along - and it will, have no doubt about that. Even if the daemon itself has limited privileges, it is going to have to talk to something setuid root in order to perform the package upgrades, so a remote root shell is only two exploits away, one for the daemon and then another for the setuid program that does the updating.
Remember, this is new code, untested in the wild for any length of time, unexamined yet by anyone external. ssh would do the job fine instead, and, although ssh has had security problems, it has had a lot of pounding on it for a long time now. The Red Carpet daemon - hasn't.
In short, wtf aren't Ximian using ssh instead of their own potentially hokey code?
Second, there is a big problem with automatic updating generally. If I can get root on a machine within a network - or in fact, just plug my laptop into this network - then with a bit of spoofing trickery I can convince any other machine within that network that I am the update server, and next time they update, they will download packages from me, which I could easily trojan - and then I've got control of every single box on the network, and almost all the work was done for me. Signed packages are supposed to alleviate this problem, but past incidents with both OpenSSL and ssh suggest that certificate checking is not always up to scratch, and there may still be other ways to convince the Red Carpet daemon to install unsigned packages. If you have an insecure wireless network attached, then you're going to have even larger problems as an attacker who wants to get in this way doesn't even have to be physically connected to your network.
This sounds like a very convenient way to automatically update software - although nothing that ssh/apt doesn't already offer - but it also sounds like a potentially gaping security hole that will bite people hard in the future.
I really liked the concept of the Ximian desktop and their easy installer and what not. I really appealed to me because I was using the *Solaris* distro that Ximian generates.
However, after a few magic rides on the Red Carpet, I decided that I wasn't all that trusting of full service. Everything worked great until I started doing the red carpet updates. Then Red Carpet would break. The icons on my desktop would break. The Evolution mailer would break.
I stopped doing updates in order to preserve something which passes as a workstation. Mind you, my case probably is extreme (but only because I tried to use Ximian for a reliable Solaris desktop), but I hope it illustrates a point.
Care to be responsible for a slew of desktops when you don't do your own quality control and bless updates which are placed onto systems you support?
If you don't want beta, just don't subscribe to the beta releases. The other stuff seems fine. This particular system is an RH7.1ish 2.4.19 kernel with Ximian Gnome.
I dont know about the normal version, but Symantec's Ghost Enterprise version allows you to install a small console on each machine, allowing you to simply reboot and reimage the machine. The downside is that you have to purchase a license for each client machine you want to run the console on. IMHO the price is reasonable, if you are talking about an enterprise size installation.
And since Ghost supports Linux, you could use it to reimage your linux boxen as well.
More on-topic, I just installed apt4rpm the other day, and it is hella cool. I always thought apt was the best feature of Debian, but I have been using RedHat for a while and feel familiar with it. There are server packages available, so you can run your own repository internally. I am preparing to do so for my company. We are primarily a RedHat shop, so this tool should prove invaluable, or at least will save me having to run around with 20 Linux CD-Rs =). I'd love to pay RedHat $20 or whatever a month per machine, but, um, no.
> for i in host1 host2 host3 ; do
> ssh $i "apt-get update ; apt-get install [package...]"
> done
Been there, done that.
You are badly mistaken if you think a simple script like this is enough to keep a large site up to date. Imagine that you have nearly 300 hosts. Imagine that although you're trying to keep the host database up-to-date there it will always not fully correspond to reality. Finally for this command to complete all of those have to be up. What if a machine crashed? What if a user shut it down? What if I machine down for whatever reason? And how long will you have to wait until this command completes? Pushing updates and such does not scale well beyond a couple of dozen boxes. No matter what toos you use for system administration, it is much better to use the pull model (where clients request updates and other configuration changes) on their own from the server instead of trying to run some command on all of them.
Maybe they will actually listen to you if you don't insult them all the time.