Ximian Testing Red Carpet Daemon 80
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.
Ximian is great.... (Score:1)
Re:How to remove Ximian (Score:1)
The original poster might try
This command has worked for me (on RH for kde.)
Re:How to remove Ximian (Score:1)
Re:Security updates? (Score:1)
Or maybe he (Neal)really doesn't know
What would be far more usefull (Score:1)
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.
autoupdate (Score:3, Informative)
Would autoupdate does installation too ? (Score:1)
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?
Re:Would autoupdate does installation too ? (Score:1)
Re:Would autoupdate does installation too ? (Score:1)
Norton Ghost works with linux. Where i work we have a lab full of dual boot (Win2k/RH linux) machines that are installed using ghost.
And since this is open source, it wouldnt be too difficult to roll your own cd that boots up, autoconfigures the machine, and installs OS. It will help if all the machines are the same configuration.
If virii writers can write apps that automatically destroy any given machine, can't we write apps that automatically create any given machine?
Re:Would autoupdate does installation too ? (Score:2)
And since Ghost supports Linux, you could use it to reimage your linux boxen as well.
More on-topic, I just installed apt4rpm [sourceforge.net] 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.
Re:Would autoupdate does installation too ? (Score:1)
Re:autoupdate (Score:1)
Been cronning apt-get upgrade for years now... (Score:2)
Good news, but ... (Score:1)
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?
Re:Good news, but ... (Score:1)
Re:Good news, but ... (Score:2)
Is there an equivalent to Norton Ghost for Linux ? (Score:1)
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 ?
Re:Is there an equivalent to Norton Ghost for Linu (Score:1)
A nice bootable CD with Partition Image included is Timo's Rescue CD [sourceforge.net]
Re:Is there an equivalent to Norton Ghost for Linu (Score:1)
I have been thinking about it. (Score:1)
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 ?
Re:Good news, but ... (Score:1, Informative)
With rc and rcd, you will be able to do automated updates from the command line. Just what redhat and redhat like distributions needed as answer for apt-get.
Re:Good news, but ... (Score:1)
I haven't tried it, but I have copied my / from on HD to the next three times now and it doesn't seem to care.
On another note... Doesn't RH have a unmanned install mode? I'm a debian guy myself, but I seem to remember RH had some tools to do auto-installs.
Can you please show me how ? (Score:1)
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 !
Re:Can you please show me how ? (Score:1, Informative)
Anyway, here's [redhat.com] a good reference, from RedHat themselves. I personally haven't done the automated installation, but I've read the manual, and it seems like an easy thing to do. They give you a template file to work with, and you just have to edit it. Pretty straightforward, I guess.
Re:Can you please show me how ? (Score:1)
The reference you linked to is very good and tells you all you might want to know. I especially like the ability to runs scripts in the %post section, for customizing after installation.
The only downside to kickstart is that if you don't have a network to play with, you're stuck with the cd's....and it can't change them for you, of course
Well, unless you fancy having a spare hard disk and installing it in every one of those hundreds of machines and doing the installs off of that.
Re:Good news, but ... (Score:1)
Re:Good news, but ... (Score:1)
You should checkout radmind [radmind.org], it's a combination tripwire/software update tool. It's being used all over the place to deploy large Mac OS X clusters. It runs on Linux, Solaris, and *BSD.
Re:Good news, but ... (Score:1)
-Aaron
So open a daemon on all networked machines? (Score:1)
Re:So open a daemon on all networked machines? (Score:2)
Re:So open a daemon on all networked machines? (Score:1)
They are leaving a hole in the system that says to the world "Your wish is my command". *Any* rc client will be able to access *all* rcd servers on the network.
You may believe the system's airtight, but people who hold that belief are often proved wrong.
No, I agree - what are Ximian smoking? (Score:5, Interesting)
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.
Re:No, I agree - what are Ximian smoking? (Score:1)
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.
It would be better to write code that will be as small as possible, which is written with the current security practices in mind. Most of the exploits which have plagued UN*X have been from old code like sendmail. That said, Ximian doesn't have the best security record. Their installation script consisted of running code downloaded over HTTP (!!) through a root shell.
Re:So open a daemon on all networked machines? (Score:1)
Not sure I'd trust this... (Score:4, Insightful)
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
Re:Not sure I'd trust this... (Score:1)
In order to update packages the 'rc' command must be run with the proper options. If it is going to install/remove packages, it will detail what actions it is about to take and wait for user input to approve the actions.
So no package will get changed unless explicit approval is given. This was true with Red Carpet GUI version, and is still true with RCD.
Re:Not sure I'd trust this... (Score:1)
The automatic updating is totally optional, and it will never "force" an update, so dependency problems can be resolved by the user.
Unless redcarpetd has the ability to prevent upgrades on selected packages I wouldn't trust it.
It does, through an .rcexclude file. It's not ideal (yet), but it's a start.
And until the packages get vetted better for conflicts I would be careful.
If you see dependency problems in our packages, it's almost certainly a bug. File it: http://bugzilla.ximian.com [ximian.com].
Unfair: Ximian are now a lot better (Score:3, Informative)
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.
debian cron-apt (Score:1)
for some time now.
Knud
Re:The arrest happened Thursday, and an on topic c (Score:1)
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.
Cautious: Burnt by Ximian. :( (Score:2)
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?
Re:Cautious: Burnt by Ximian. :( (Score:2, Informative)
Granted, some operating systems handle updates differently than others, but, using Red Hat Linux 7.3 as an example, this month alone there have 58 packages released as errata. RCD will tell you which of these apply to your system, and can, optionally, install them for you. However it will not ever install something unless a user directly tells it to.
As the original post says "Can you be responsible for a slew of deesktops when you don't
Re:Cautious: Burnt by Ximian. :( (Score:2)
I have to somewhat agree.
Occasionally, due to a bug, or more often due to me running out of HD space, the install for a core RPM like 'red-carpet' or 'rpm' would die. Then I'd be stuck without red-carpet or rpm, and would have to restore these programms by grabbing a bootstrap install from Ximian or elsewhere.
But there is a reson for this: Ximian only has one person in charge of repackaging/testing the Solaris RPMs. This is in large part due to the fact that Solaris users make up a very small percentage of the Ximian and Gnome market (Heck, less then 1% of the visitors to Gnomedesktop.com use Solaris [gnomedesktop.com])
This may improve as Gnome2.0 matures, after Ximian reduces their support for Gnome1.4 in favor of Gnome2.x, and after Sun releases their Gnome2.0 distro.
Don't cron apt! (Score:1, Informative)
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
Apt-RPM (Score:1)
Apt in Cron (Score:1)
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.
Nothing like an overloaded program name... (Score:1)
Couldn't you have been just a little more creative in coming up with a name? Geez. Now we get:
Hurrah for Xidiot.Re:Nothing like an overloaded program name... (Score:2)
simples scripts and ssh, or reinventing the wheel (Score:1)
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.
Re:simples scripts and ssh, or reinventing the whe (Score:2)
> 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.
Re:simples scripts and ssh, or reinventing the whe (Score:1)
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.