Re: reset perms and ownerships
On Mi, 23 oct 13, 20:57:30, Bob Proulx wrote: The dlocate command is a fast indexed 'dpkg -S' command. You will likely need to 'apt-get install dlocate' to have it but it is so much faster than 'dpkg -S' that it is very useful to install. Cool! Thanks for the tip, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
reset perms and ownerships
Hi, ( this is most likely a RTFM question, please just point me to the right FM) One inexperienced colleague just something along the likes of... sudo chown someuser:somegroup / ; sudo chmod someperms / (it's actually a little more elaborate than that, but you get the picture) ... and then came back to me for help. I'm a sysadmin on the RH/CentOS camp, and my confort level with apt-* and dpkg* is extremely low. Is there anything like rpm -V on the debian toolset? I'm trying to avoid punishing him (further) with reinstall... Thanks in advance, Mário Barbosa -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5267bd5a.70...@gmail.com
Re: reset perms and ownerships
Le 23.10.2013 14:13, Mário Barbosa a écrit : Hi, ( this is most likely a RTFM question, please just point me to the right FM) One inexperienced colleague just something along the likes of... sudo chown someuser:somegroup / ; sudo chmod someperms / (it's actually a little more elaborate than that, but you get the picture) ... and then came back to me for help. Hopefully he'll remember that using super user powers have to be made with care :) I'm a sysadmin on the RH/CentOS camp, and my confort level with apt-* and dpkg* is extremely low. Is there anything like rpm -V on the debian toolset? I'm trying to avoid punishing him (further) with reinstall... It does not do any control (which is the role of rpm -V if I understood correctly the man), but apt-get --reinstall might help. But if he did the changes on /etc, it won't work, because configuration files won't be modified ( it removes and installs, not purge and installs ). I think you might have solutions, but what has been changed, exactly? Software binaries in /usr? Configuration files in /etc? Other stuff in /var? Maybe simply changing back the perms and ownerships might be simpler, too. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eb6a41a64711a36653a17e3786880...@neutralite.org
Re: reset perms and ownerships
Hi, On 10/23/2013 01:33 PM, berenger.mo...@neutralite.org wrote: [...] Hopefully he'll remember that using super user powers have to be made with care :) He will. :) Is there anything like rpm -V on the debian toolset? I'm trying to avoid punishing him (further) with reinstall... It does not do any control (which is the role of rpm -V if I understood correctly the man), but apt-get --reinstall might help. But if he did the changes on /etc, it won't work, because configuration files won't be modified ( it removes and installs, not purge and installs ). I already did something along the lines of... cd /var/cache/apt/archives ls -1 *.deb | xargs sudo dpkg -Gi (after manually fixing ownerships on sudo binaries, working dir's, and config/data files) ... which apparently solves some of the problems, but is far from fixing everything (ownerships of /etc and /var being just two examples). I think you might have solutions, but what has been changed, exactly? Software binaries in /usr? Configuration files in /etc? Other stuff in /var? Upon further investigation, here's what was done: sudo chown -R someuser:somegroup / Maybe simply changing back the perms and ownerships might be simpler, too. Thought about it, but I have no reference to mimic (meaning: I have no definite list of previous user and group ownerships to refer/compare to). Guess I'll bite the bullet and reinstall the machine (with the added advantage of solving other - unrelated - problems). Thank you for your help, Mário Barbosa -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5267cf3e.9050...@gmail.com
Re: reset perms and ownerships
Le 23.10.2013 15:29, Mário Barbosa a écrit : Hi, On 10/23/2013 01:33 PM, berenger.mo...@neutralite.org wrote: [...] Hopefully he'll remember that using super user powers have to be made with care :) He will. :) Is there anything like rpm -V on the debian toolset? I'm trying to avoid punishing him (further) with reinstall... It does not do any control (which is the role of rpm -V if I understood correctly the man), but apt-get --reinstall might help. But if he did the changes on /etc, it won't work, because configuration files won't be modified ( it removes and installs, not purge and installs ). I already did something along the lines of... cd /var/cache/apt/archives ls -1 *.deb | xargs sudo dpkg -Gi But this will install everything you installed if you never cleaned that dir... you may find useful this command in the future: $ aptitude search '~i' The ~i means all installed packages. The generated list will include all automatically installed packages so it's not perfect for your needs, but I do not remember the exact syntax to exclude them. Aptitude's manual should help here. (after manually fixing ownerships on sudo binaries, working dir's, and config/data files) ... which apparently solves some of the problems, but is far from fixing everything (ownerships of /etc and /var being just two examples). I think you might have solutions, but what has been changed, exactly? Software binaries in /usr? Configuration files in /etc? Other stuff in /var? Upon further investigation, here's what was done: sudo chown -R someuser:somegroup / wow... he really did that on /. You could add to the lesson to never use recursive changes on root directory I guess... Maybe simply changing back the perms and ownerships might be simpler, too. Thought about it, but I have no reference to mimic (meaning: I have no definite list of previous user and group ownerships to refer/compare to). Guess I'll bite the bullet and reinstall the machine (with the added advantage of solving other - unrelated - problems). You could try to not reinstall the whole system with installer, but simply use aptitude (with the ncurse interface) to purge (and not remove, so that configuration files are removed and reinstalled) all packages. Then, installing them back, if you know what you need. Given that you still have the files in /var/cache/apt/archives it should not involve any downloading, and you will skip the installer's questions. Between the purge and reinstalling, you could probably change back every ownership and perms to root in / (except /home of course) and remove users and groups which could have been installed by packages. It is simply a solution which might be faster than reinstalling. Or not, it depends on what you have installed so far. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b6c307dee7091fe054504fad170dd...@neutralite.org
Re: reset perms and ownerships
On 10/23/2013 02:48 PM, berenger.mo...@neutralite.org wrote: I already did something along the lines of... cd /var/cache/apt/archives ls -1 *.deb | xargs sudo dpkg -Gi But this will install everything you installed if you never cleaned that dir... you may find useful this command in the future: $ aptitude search '~i' The ~i means all installed packages. The generated list will include all automatically installed packages so it's not perfect for your needs, but I do not remember the exact syntax to exclude them. Aptitude's manual should help here. Thank you for this tip. Added it to my toolbox (my own private command cheat sheets). [...] Upon further investigation, here's what was done: sudo chown -R someuser:somegroup / wow... he really did that on /. You could add to the lesson to never use recursive changes on root directory I guess... In his defense, his only mistake was running a post-receive hook out of its context (different current dir, different user). What is written in that hook/script is my responsibility. Rhetoric: * Should he have done it? No. * Should I have enforced proper working dir? Probably yes. He is not a sysadmin, so maybe I should have anticipated some of these wildcard type of actions... You could try to not reinstall the whole system with installer, but simply use aptitude (with the ncurse interface) to purge (and not remove, so that configuration files are removed and reinstalled) all packages. Then, installing them back, if you know what you need. Given that you still have the files in /var/cache/apt/archives it should not involve any downloading, and you will skip the installer's questions. Between the purge and reinstalling, you could probably change back every ownership and perms to root in / (except /home of course) and remove users and groups which could have been installed by packages. It is simply a solution which might be faster than reinstalling. Or not, it depends on what you have installed so far. The idea of purging config files scares me quite a bit. Are edited files saved somewhere (like rpm does with the .rpmsave extensions)? Maybe then I'm trading one type of problem for another (the new one being validating that every config is set as needed)... Berenger, thank you for your help. Please, waste no more of your time on this. Best, Mário Barbosa -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5267dc2a.9070...@gmail.com
Re: reset perms and ownerships
Le 23.10.2013 16:24, Mário Barbosa a écrit : On 10/23/2013 02:48 PM, berenger.mo...@neutralite.org wrote: I already did something along the lines of... cd /var/cache/apt/archives ls -1 *.deb | xargs sudo dpkg -Gi But this will install everything you installed if you never cleaned that dir... you may find useful this command in the future: $ aptitude search '~i' The ~i means all installed packages. The generated list will include all automatically installed packages so it's not perfect for your needs, but I do not remember the exact syntax to exclude them. Aptitude's manual should help here. Thank you for this tip. Added it to my toolbox (my own private command cheat sheets). [...] Upon further investigation, here's what was done: sudo chown -R someuser:somegroup / wow... he really did that on /. You could add to the lesson to never use recursive changes on root directory I guess... In his defense, his only mistake was running a post-receive hook out of its context (different current dir, different user). What is written in that hook/script is my responsibility. Rhetoric: * Should he have done it? No. * Should I have enforced proper working dir? Probably yes. He is not a sysadmin, so maybe I should have anticipated some of these wildcard type of actions... Checking all external data is always a good idea in programming. Users (humans or external softwares) can do really strange things sometimes. You could try to not reinstall the whole system with installer, but simply use aptitude (with the ncurse interface) to purge (and not remove, so that configuration files are removed and reinstalled) all packages. Then, installing them back, if you know what you need. Given that you still have the files in /var/cache/apt/archives it should not involve any downloading, and you will skip the installer's questions. Between the purge and reinstalling, you could probably change back every ownership and perms to root in / (except /home of course) and remove users and groups which could have been installed by packages. It is simply a solution which might be faster than reinstalling. Or not, it depends on what you have installed so far. The idea of purging config files scares me quite a bit. Are edited files saved somewhere (like rpm does with the .rpmsave extensions)? Maybe then I'm trading one type of problem for another (the new one being validating that every config is set as needed)... No, they are not saved, you have to do that manually (but it only affects those in /etc, not userland files). Exactly as if you were trying to reinstall from scratch, in fact. Berenger, thank you for your help. Please, waste no more of your time on this. Not a real loss of time. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ce16e902ab687b3d36743e111a349...@neutralite.org
Re: reset perms and ownerships
Mário Barbosa wrote:
sudo chown -R someuser:somegroup /
... and then came back to me for help.
Oh my goodness!
I'm a sysadmin on the RH/CentOS camp, and my confort level with
apt-* and dpkg* is extremely low.
Is there anything like rpm -V on the debian toolset? I'm trying to
avoid punishing him (further) with reinstall...
Because this is ownership and permissions I don't think there is a
completely trivial solution. There is 'debsums'. But that won't be
sufficient since it is looking specifically at file content. And I
saw the other suggestions. I would NOT have done a dpkg -Gi on the
archives directory.
(I may have done an apt-get install --reinstall on a list of packages
that were installed on the system, a list from dpkg -l | awk
'{print$2}'. But that would blow up the apt extended_states file and
marked everything as manually installed. See 'man apt-mark'. Would
have saved it off before and restored it aftward.
cp /var/lib/apt/extended_states /root/
apt-get install --reinstall $(dpkg -l | awk '{print$2}')
cp /root/extended_states /var/lib/apt/
You get the idea.
)
Here is what I would have done. If I were wanting to save the
system rather than install again.
I assume the system is very unhappy. I would mount the disk on a
different good system and save it from there. Otherwise I would work
across two systems. Reset the values from the known good to the
mangled.
I would generate a list of files on the mangled system. Avoid all of
the tmpfs and proc filesystems. Then I would do the same on the host
system or a different known good similar system used as a reference.
Then I would find the common set of files between the two. I would
see what ownership and permissions lived on the good system for those
files and generate a script to set the mangled system to the same. I
would just do it on the fly on the command line using grep and sort
and awk and comm and those types of things.
Of course that is where the work is done but I would scramble around
and convert 'stat' output into commands to reproduce the ownership and
permissions.
xargs stat --printf chown %U %n\n filelist cmdfile
That will be broken for any files with whitespace in it but the system
doesn't have any of those. Inspect for whitespace and scrape those
out and handle manually. Then do the same for permissions. And so
forth. Craft the script to restore the ownership and permissions.
Then run the script!
Be careful not to break the host system with an absolute path to the
target system! (I did that once so am speaking from experience.
D'oh!) That should get 90% of everything back into good shape again.
Use a good reference system to determine what ownership and permission
the mangled system should have.
That will still leave some files that are installed on the mangled
system that do not have known good info from the reference system.
Take that list and run it through 'dlocate'. The dlocate command is a
fast indexed 'dpkg -S' command. You will likely need to 'apt-get
install dlocate' to have it but it is so much faster than 'dpkg -S'
that it is very useful to install.
xargs dlocate filelist | awk '{print$1}' | sort -u pkglist
That will produce a packge list of the files that you don't have
information for. I would possibly install those on a test system just
to get the right ownerships and permissons for them. I would install
in a VM and then throw the VM away afterward. I create a lot of
throwaway VMs for testing things like this so for me that is natural.
But a real machine would be fine too.
Or probably for 99% of those files you would know immediately what
needs to be done by visual inspection and would just do the right
chown and chmod commands to fix it. But at least by that time it
would be a much smaller list. Then I would probably have done the
apt-get install --reinstall of every installed package as discussed
above just to be as safe as possible.
I know this probably isn't helpful now at this late date. But that
type of thing is the way I would have attacked the problem. There
isn't any canonically right answer. At some point everyone just uses
their best judgement and muddles through these problems as best as
they can.
Bob
signature.asc
Description: Digital signature
