SDUX reinstall vs reinstall_files

[Erwin Mascardo]

For our software developed in-house, we use standard SD/UX programs to distribute them across the network. However, we don't (yet) use any sort of versioning or revision labeling, so we're forced to use "reinstall=true" to make sure the packages get installed. This ends up wasting a lot of bandwidth, particularly to the locations which are connected via WAN links.

Often, it's just one or two files out of a whole package that have been changed. Looking at /usr/lib/sw/sys.defaults, it appears that the reinstall_files option keeps unchanged files from being recopied. However, it seems that the reinstall option overrides this, and everything gets sent anyhow. (The machine that we deploy from is on 11.00.)

Is there any way around this, or do we just have to implement versioning like we've been meaning to for a few years now?

[Ramkumar Devanathan]

Hi Erwin,

Since you don't use versioning it doesn't matter if you do a SD reinstall.

Why don't you find the difference between the depot's contents in terms of files changed and ftp those files alone to the specific locations where they are expected to be present (so that the original files get overwritten)? - in any case, SD would also do the same thing.

FWIW.
- ramd.

[Erwin Mascardo]

It's for the sake of our sanity. Our deployments involve close on 100 machines, with many different software configurations. Typical deployments see several hundred files being changed in total across about 150 different filesets, with a given machine receiving anywhere from 10 to 80+ filesets depending on its role and the size of the deployment. If we used manual ftp with manual picking and choosing of files, the whole IT group would be reduced to a gang of gibbering idiots before a deploy was 25% finished. (And this is different from normal how? *grin*)

We have scripts in place that determine which box gets what, but in the end, it calls swinstall. It's the only way to get things done in a timely fashion.

[Ramkumar Devanathan]

Ouch! Ok i get your point Erwin.

Maybe you could use cvs or some other tool and synch the workstations - every week say. that again means you have to install cvs on all the machines... (i don't know what all options cvs or other versioning systems may offer).

Before I start being more creative (or silly) - get back to me with what you believe will solve your problem. :)

- ramd.

[Steven E. Protter]

You probably should consider distributing patches and other software images on an Ignite Server.

This would allow you to keep multiple images for your various classes of machines. You can even do script customization to make sure special circumstances are handled for particular machines and workstations.

Its a great way to manage SD-UX patches and HP supports it.

Doing distribution by ftp is not really supported and if something goes wrong you're not in a good support situation.

SEP

[Erwin Mascardo]

Thanks anyhow, but after some consultation with Those In Charge, it's been decided that we'll just have to cope. Someday, we may introduce version control, and that will solve a lot of the headaches (as well as introduce some new ones, but such is the way of the world).

[harry d brown jr]

Why not just bundle up the differences manually? Are you gzip'ing (option -9 gives best compression) the files before sending them?

Would it be difficult to use something as simple as sccs??

live free or die
harry

[Tim Sanko]

I am really lazy, and this is the way I solved the problem.

Back in the days of manually maintaining DNS and reverse resolution tables... (OK, I'm OLD) The header had a version.) every time it changes increment the header.)

it would take just forever to
read the files from a list and grep for the current version in a for loop....

That allows the simplistic version control, and doesn't complicate the world. It might even make management happy.

NAH!

Tim

[Erwin Mascardo]

The biggest problem at the moment is inertia. We've deployed software like this since long before I started here, and it would be a major project on multiple levels to change the underlying mechanism...which is highly unlikely to happen, since of course we'd need a separate environment for testing the new mechanism. We need a proverbial one-line fix, and while all of these suggestions are good, they're also too complex to implement easily. Thanks anyhow.