Re: [Hampshire] Application installers

On 19/02/2008, Vic <lug@???> wrote:
> >> # rpm -q kernel-smp
> >> kernel-smp-2.6.9-55.0.2.EL
> >> kernel-smp-2.6.9-55.0.6.EL
> >> kernel-smp-2.6.9-55.0.12.EL
> >
> > Right, and each one of these kernels has a version number appended to
> > the file name
>
> No, those are the package names.
>
> Some of the filenames within those packages have version numbers appended,
> some don't.

And the ones that don't have a version number must work with every
version or the whole thing will fail.


> > Gets a little more complicated if you need different versions of bash
> > or something like that though. You can only have one /bin/bash.
>
> Yes, but you can have multiple $INSTALL_DIR/bin/bash . This is the sort of
> trick you pull to get clashing packages to install on the same system.
> It's hardly rocket science...

This is the same thing. Instead of appending a version number you are
prepending some extra directories.

>
> > If anything, installing as a regular user prevents the kinds of
> > privilege escalations that suid apps have.
>
> So don't do suid apps. Use administrative privilege to do administrative
> tasks (like installing software), and use user privilege for doing user
> taks (like running it).

In the perfect world, where every user has root access or does not
have to wait a week for their IT provider to turn up and do an
install, you would be absolutely right.


>
> > Write access is needed only
> > during the install and when doing upgrades.
>
> root privilege is needed only during install and upgrade...
>
> >> No, I can't see that. I think it makes no sense under any circumstance.
> >> Sorry, an' that...
> >
> > Let's see, 100 users each with even the minimal 2GB install would
> > require an extra 200GB backup media.
>
> You're fixated on the idea that every user needs to be able to do
> installs, and you're breaking the security model to achieve this.

Our customers require this. The "wait a week for their IT to do an
install" comment may sound like fiction but sadly, particularly in the
larger companies, it is becoming more and more the norm.

Rich


>
> If you merely reserve admin privilege for what it's designed for, you get
> *one* installation system-wide that doesn't get broken as soon as some
> clueless user has a "good idea". If you want each user to be able to patch
> his own view of life, build a link farm in his home area & let him play
> with that.
>
> > Seems to make sense to me not to
> > put it in the home area. I know what you are gonna say now, backup
> > scripts can be more intelligent than that, but now you have to have
> > someone write this backup script that knows not to backup this one
> > particular directory (which could be named anything the user wants)...
>
> Why are you backing up programme and data areas together?
>
> You only need one backup of system-wide stuff (e.g. the app).
>
> You make individual backups of individual stuff (e.g. user data).
>
> Confusing the two will only lead to your backups becoming bloated beyond
> the point of usefulness.
>
> > Anyway, I am not sure why I am defending InstallShield. I was simply
> > answering a question about other installers and since I have not used
> > the ones mentioned I thought I would point out that InstallShield was
> > another option.
>
> Yes, but you're also making assertions about the way things need to be
> done when in fact that need is only the result of your own (broken) rules.
> As this is an archived and searchable resource, I wouldn't want that going
> unchallenged, as someone reading this might think it's a good idea to do
> it that way.