[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-developers] screwed up file ownership and permissions
- Subject: Re: [cobalt-developers] screwed up file ownership and permissions
- From: Rob Montgomery <Rob@xxxxxxxxxxxxxxxxxx>
- Date: Mon Apr 9 16:52:26 2001
- Organization: Realm Solutions, Inc
- List-id: Discussion Forum for developers on Cobalt Networks products <cobalt-developers.list.cobalt.com>
Duh, never mind. You ever have one of those things that you just cant
figure out, but its because of a really stupid reason? Well this was it...
I was sidetracked completely by his previous chown -R blunder, blaming
it for the problem!
My client emailed me saying he cant get into <virtualsite>/admin, and
that something was wrong.... Since I never use the admin web-interface
in the first place, and this is the only client I have using cobalt, I didnt
know that it is <virtualsite>/siteadmin, and not /admin... I finally figured
it out after investigating the admserv httpd.conf file...
Thanks for your time and help!
Rob
Chris Johnson wrote:
> > From: Rob Montgomery <Rob@xxxxxxxxxxxxxxxxxx>
> >
> > [My client] did a chown -R as root and royally screwed
> > up the machine.
>
> It isn't pleasant, but you can do
> % rpm -V -a
> .
> .
> .
> S.5....T c /etc/printcap
>
> and get a list of all the files that the RPM database thinks
> have been modified. The files that have had their mode bits
> changes will get a 'M' flag as the second character in the
> first field.
>
> So
> % rpm -V -a | egrep '^.M'
> Should give you a list of everything that has been changed.
>
> You can then try to fix things by hand, or look at another
> Cobalt box for the right value. You can also grab most of
> our rpms from
> ftp.cobaltnet.com/pub/products/
>
> Be careful about installing rpms to be sure that you don't
> downrev things. Use 'rpm -q -f' to get the rpm version, and
> look for that RPM, either in the product directories, or the
> updates.
>
> It seems to me that you should be able to get the target
> modes from the RPM databases in /var/lib/rpm, but I don't
> see an easy way other than hacking up a perl script and
> decyphering the rpm record format.
>
> cj*