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.
Unless you ever want straight up Gnome again. Then, good luck removing Ximian Gnome! ;) Although Ximian Gnome was really slick!
Long live Helix code!
Oh, wait... (removes head from sand)
What if you just cron apt-get to get security updates from security.debian.org? I'm just curious since I've only been using Debian a year now and run all my updates by hand. It'd be nice to have security updates apply automatically though. :-)
Is a daemon that would work as a server for evolution ala exchange. Now if I could get exchange without Windows and Evolution on every desktop (even the ones with windows) I would buy.
I think it is great that they are trying, but really, how many companies have linux on every desktop? I can't see taking our sales/marketing/support staff off Windows.
apt-get install redhat please god - Me (take it easy, I love Debian)
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.
I'm about to download IBM's JDK. I gave up with Java on Mozilla ages ago..
I have just paid my $10 (yes, I'm a student). That and Mathematica are now the two non-open-source packages on my BSD machine, and both extremely worthwhile purchases.
...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
What Ximian does is indeed good.
I have to configure hundreds of desktops in Linux, and many of the time the configurations are the same.
It has been a very time consuming task, and I do hope that there is a better way to do so than the manual procedure I have been doing.
I do know that if the desktops are linked (networked) I can automate the process, but unfortunately, they are NOT linked.
So I am searching for a way to configure ONE desktop, then copy the ENTIRE hard disk content on CD-R (or similar mass storage devices) and then go to another (empty, not yet configured) desktop, boot up with the CD-R and then automate the process.
I hope the Ximian new product will do that.
And there's a BUT.
The BUT is, Ximian only runs on Gnome. Many of the time the configuration I do is to get Linux runs on Chinese, hence, I have to use KDE.
Is there a way to mass configure desktops with KDE?
Sounds like an invitation to find the vulnerability.
I have been pwned because my
If they made a customised KDE and not crappy gnome.
You can't get much easier than "rpm -U `rpm -qa|grep '\.ximian\.`".
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
I have been using the the debian cron-apt package
for some time now.
Knud
I do know that Norton Ghost is under the spell of Windowsism, and I have been searching for similar utility that runs under Linux.
Is there any ?
But if possible, I would want to remain doing things under Linux.
So, is there any utility that runs under Linux that matches the ability of Norton Ghost ?
Anyone ?
Mono is now available as a red-carpet channel.
Damn the hordes of .net naysayers! I've just installed it... looking good with gtk# bindings.
You sez:
"Red had comes with the kickstart configuration.
Just a simple text file that you can use to do automated installs.
Pretty handly for PCs with the exact same configuration.
But that's just installation, you also want to keep all
those systems updated automatically."
Thank you for the info !
Can anyone show me where to how to do that ?
My problem is I'm overwhelmed by too many "How-Tos", and I just don't know where to start.
If anyone can point me to one (or several critical) howtos, or simply show me HOW to do automate the installation _and_ update, I'd be extremely grateful !
Thanks in advance !
This arrest is news, not NEWS. Sorry, friends don't let friends use Gnome;-) I Haven't tried a Gnome setup yet that didn't crash my box in less than 10 minutes, and get permanently ignored from then on.
it's just gonna be fucking subscription-ware anyways...
Try Partion Image
A nice bootable CD with Partition Image included is Timo's Rescue CD
Thank you for the tips about autoupdate.
I want to know if it can be used for installation / configuration for new machines, as well as update ?
I have to set up hundred of desktops in Linux, and most of the configurations are the same. The desktops are not networked, so I have to finish the job manually.
I am looking for a way to automate the process, or at least a way to lesson the task.
I am thinking of setting up a machine, using a utility that works like "Norton Ghost" (if there is such a utility that runs under Linux, there'd be super-nice !), where I can "copy" the whole content of the harddisk (partitions and all) into a CD-R.
Using that CD-R, I can go to other empty, yet-to-be-configured, desktops, boot up the machine on the CD-R, and then "replicate" the set-up (partitions and all) on that machine, automatically.
That will at least takes care of the set-up part.
I know autoupdate does the updating, so I am wondering if autoupdate does the "setting up" too?
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?
rushing to put a crash-prone beta-version of some administration software on their system.
Sometimes I wonder if there is no thing like "code red" on linux systems because there is no need for such things.
Owner of a Mensa membership card.
Hopefully this works out better than the time I cronned apt-get upgrade under Debian's unstable tree. Whoops.
... :)
Debian has three trees; stable, testing and unstable.
When using the stable tree, instead of using cron, subscribe to debian-security-announce and only update when a package with a security problem needs updating.
Update scripts also often need to ask you questions and cron doesn't allow that - and testing and unstable sometimes break on update, because they are not, well, as stable - they need to be watched.
Offhand comments like the above make debian seem flakey when it is far easier to maintain and stable than red hat, because debian is built robustly from the ground up.
How hard is it to check mail and apt-get update; apt-get upgrade when needed?
Anyway
dd
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.
So... Do you assume that everyone who uses GNOME has the same experience as you, and uses the software anyhow? Did it ever occur to you to wonder if perhaps the problem is just that you're incompetent or perhaps that your hardware sucks? Probably not. Judging by the incoherent nature of your post, you're either mentally ill or fucked up on something.
This is not a GNOME vs. KDE vs. TWM flame... Just a flame against stupid people.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
See my other post. Ghost works with Linux. It costs, but it works.
The best of both worlds Apt with the huge set of packages available for RPM. http://apt-rpm.tuxfamily.org/ I have been using this for a while to keep about 50 machines upto date.. I also have it set up with an "extras" hierarchy so that I can run newer versions of stuff like mozilla...
Hopefully this works out better than the time I cronned apt-get upgrade under Debian's unstable tree
Yeah, no shit. When I FIRST started using Debian, I did pretty much the same thing, because I didn't have cable yet and wanted the downloads to go off while I was out (out being sporadic, I had a script that I'd fire off as I left).
One time I came home and had no X, no e-mail, about half of the programming tools I needed for class, and no cache of packages (disks were smaller then), so I also was SOL on any quick way to reinstall it.
Looks like Ximian will tank like Eazel, Progeny and their friend TurboLinux.
Couldn't you have been just a little more creative in coming up with a name? Geez. Now we get:
Hurrah for Xidiot.:: "I am non-refutable." --Enik the Altrusian ::
what does this red-carpet thing do that something
.rpm packages to the machine and then used
like the following doesn't do:
for i in host1 host2 host3 ; do
ssh $i "apt-get update ; apt-get install [package...]"
done
a useful variant (for more complicated upgrades)
is to write a sh script to do the upgrade, scp it
to the remote machines and run it with ssh. this
script can install/upgrade the packages, run perl
or whatever to customise config files, and do
anything else that is needed to ensure that the
upgrade goes smoothly.
i've used variations of the above script to
install or upgrade single packages and even full
system upgrades on dozens of remotely-located
debian boxes in one go (mostly internet gateways,
firewalls, proxy servers etc).
for rpm-based systems it would be trivial to
modify the script so that it used scp to copy the
require
ssh to run rpm for the install.
all i see is another unneccessary daemon which
gives remote root privileges which hasn't had
anywhere near the security testing of ssh.
IMO, anyone who isn't capable of writing trivial
scripts like the above has no business pretending
to be a sysadmin and shouldn't be upgrading even
one machine, let alone batches of them.
Yes, Debian got this functionality (I use debian myself). However, personally I think the biggest win is the same tools to install and update the system on all the platforms Ximian support (which is most popular linux-distributions and Solaris).
> 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.
All these tools only installing rpm packages from a ftp/file/http server. (and try to be unnecessary smart)
This can be done easier. For remote system administration I use/wrote a tool which distributes rpm install lists, based on the hostname.
rather simple/insecure:
netcat rpm.list.server -p 666 "myhostname"
on the server side you can very easily maintain "computer groups" (clients,servers,devel,..)
Every client sends once per day its id and gets an assigned list.
Then it updates/install/removes packages based on this list. No autoupdate needed, no autorpm or any other tool, very easy and much less code than autoupdate (or any other tool).
> Been there, done that.
so have i. it works.
> You are badly mistaken if you think a simple
> script like this is enough to keep a large site
> up to date.
no, i'm not. this isn't just theoretical, this
is what i do to maintain a large network of
(currently) dozens of machines. in the past, i
have used similar techniques to maintain networks
of hundreds of machines. it works.
> Imagine that although you're trying to keep the
> host database up-to-date there it will always
> not fully correspond to reality.
if i was so slack that i couldn't even maintain
a simple database like that then i'd deserve to
be sacked.
if nothing else, i'd be maintaining the DNS
records that point to all those machines.
> Finally for this command to complete all of
> those have to be up. What if a machine crashed?
you use a semaphore of some sort (e.g. touch a
file where the filename = hostname) to indicate
whether the upgrade has completed or not. then
you just run the script again when you've got the
crashed machine(s) back up again. no problem.
and since we're talking about dozens or hundreds
of machines here, tee the output of the script
so that you can leave it running overnight and
review the log in the morning. stuff like this
should be obvious.
frankly, you don't know what you're talking about.