« previous: Musicbox Version Old.0 | next: 2004 Saturn Ion Owners Manual »

No Subject

There is this brilliant guy I have been working with that really knows the ins/outs of Win32 application packaging, group policy software deployment and many other M$ tricks.

I keep trying to get him into more open source.  He says he has no reason to move away from the Windows registry and DLLs.  There isn’t much he can’t do with Install Shield Admin Studio and GPMC.  He asked me how easy it would be to administer a Linux desktop.  I couldn’t speak at length, but I explained what I know (running as different user accounts, editing configuration text files, reloading the "kicker", running entire installation read-only).

I was hoping to get some good examples of how to make configuration changes and centrally push software to Linux desktops.  He is very good at doing this with Windows desktops and would really groove on checking it out on Linux.

Posted by Patrick Copland on Aug 13, 2004 | 10 replies
Filed under: General

Comments:

01. Aug 14, 2004 at 08:15pm by Kev:

I don’t see why he couldn’t use some simple bash shell scripts, combined with cron jobs to check the central server and copy the new configurations. It’s pretty trivial actually, and being that he is a quote/unquote windows guru, he should know how to write DOS batch files, so transferring that sort of thinking to bash should not be a problem.
HTH

02. Aug 16, 2004 at 09:32pm by Patrick Copland:

Being as I don’t understand what constitutes a "software package" in Linux, I wouldn’t know where to start to explain how to push software to a Linux workstation.

An example:  silently install Open Office using default settings to a running Linux workstation and have it apply to a specific profile.  Also, make changes to add quick launch to the kicker.

03. Aug 17, 2004 at 12:47am by Kev:

If it’s an RPM based distribution: RedHat, Fedora, SuSE and Mandrake for examples, you could use YUM which is sort of like apt (apt-get) on Debian based distros, but it is more suited to RPM packages. If the OpenOffice.org RPMs for the particular distribution are directly built by and for the distribution, they will have the proper menu items added to the "K" menu in the kicker "taskbar". This can be accomplished through an SSH connection with root privileges: "[root@remotebox root]$yum install openoffice" would do the trick.

04. Aug 17, 2004 at 11:01am by Patrick Copland:

Of course!  I will gather some info. on RPM/yum and get his feedback on that.  If he can start with RPM creation, he will probably continue on from there.

Much thanks.

05. Aug 17, 2004 at 10:17pm by Kev:

No problem (:
If you have more questions or need more help, email me.

06. Aug 18, 2004 at 01:04pm by Anthony:

I’m not familiar with any group deployment solutions on *nix, so I can’t add much here.  (And of course, SSHing into a box and doing the installation will work... but that isn’t a centralized solution since you’d have to do it once per client, and it isn’t actually a "push" solution either since it’s interactive.)

07. Aug 18, 2004 at 01:21pm by Kev:

I was saying you could use ssh to get in to make scripting changes if needed. A cron job (00,30 * * * * /root/runyumupdate) on each client should be installed, and it would run every half hour in this case and it could run something like:

#!/bin/bash
# This file is called /root/runyumupdate
# This script will run yum and update installed packages with new versions as necessary (Automatically!)
yum -y update

Of course you would need to change permissions to execute this script:
chmod a+x /root/runyumupdate

Keeping your own yum tree on a server in-house keeps bandwidth to the Internet down also, and gives you more control over which packages get deployed to client systems.

08. Aug 18, 2004 at 01:45pm by Anthony:

Sure, but that’s a pull (each client pulls updates from server, on a schedule) rather than a push (server pushes updates to all clients, at the admin’s discretion).  I thought Patrick was referring to the latter, but maybe he wasn’t, and/or maybe the distinction doesn’t matter for his application.  If all he wants is to keep the clients up to date when new package versions are released, then cron+(yum|apt-get|emerge|etc) is definitely the way to go.

09. Aug 18, 2004 at 04:57pm by Kev:

Ah, point taken: push vs. pull. I didn’t even think of it that way...

10. Aug 18, 2004 at 08:56pm by Patrick Copland:

Push/pull happens when either the computer is booted (if applied to computer account) or user logs in (if applied to user or group).  Computer checks for policy changes and policy initiates installation of new software without requiring user elevated priviledges.

An example of what my friend can do is:

Package an application to install at system boot or user login.

Specify a transform file during push to modify the default installation (such as desktop icon or change working directory path).

Modify desktop settings (wallpaper, screensaver, shortcuts in start menu, drive connections, other user environment settings).

When policy is changed and no longer includes software or desktop/user environment changes, software is "magically" removed and settings go back to default.

I am positive that Linux desktops can be infinitely better managed than buggy Windows desktops.  For one, the only sure way to get policies to apply is to reboot.  Nothing happens in real time.

Reply to this message here:

Your name
Email
Website (optional)
Subject

[ Home – Create Post – Archives – Login – CMS by Encodable ]