Description of problem: When katello-backup is stored on NFS share exported with the root_squash option it fails on chown operation. This means that for the destination directory, where the backup will be finally saved, the user creating the backup is no longer root, it is user nobody. Therefore, in the way you are running the backup, it is run by root as far as reading files from the system is concerned, but when it comes to writing files to the destination directory, the user is "squashed" to nobody. Version-Release number of selected component (if applicable): Satellite 6.2.x How reproducible: 100% Steps to Reproduce: 1. Setup NFS share with root_squash option 2. Call katello-backup on that directory 3. # katello-backup --online-backup /mnt/backup/20170103-root Creating backup folder /mnt/backup/20170103-root /usr/share/ruby/fileutils.rb:1341:in `chown': Operation not permitted - /mnt/backup/20170103-root (Errno::EPERM) from /usr/share/ruby/fileutils.rb:1341:in `chown' from /usr/share/ruby/fileutils.rb:1034:in `block in chown' from /usr/share/ruby/fileutils.rb:1033:in `each' from /usr/share/ruby/fileutils.rb:1033:in `chown' from /bin/katello-backup:48:in `<main>' Actual results: As seen above. Expected results: Backup taken successfully. Additional info: When commenting chown operation in katello-backup and katello-restore backup was taken and restored successfully. katello-backup ~~~ 46 FileUtils.mkdir_p(@dir) 47 puts "Creating backup folder #{@dir}" 48 # FileUtils.chown(nil, 'postgres', @dir) 49 FileUtils.chmod 0770, @dir 50 FileUtils.cd @dir ~~~ katello-restore ~~~ 19 def restore 20 puts "#{DIR}" 21 # FileUtils.chown(nil, 'postgres', DIR) 22 Dir.chdir(DIR) ~~~
Created redmine issue http://projects.theforeman.org/issues/18331 from this bug
Hello, I am in the process of creating a KCS article for this BZ. I understand that the chown that fails: FileUtils.chown(nil, 'postgres', @dir) is trying to change the ownership of the directory to the database group. To me it seems unsafe to proceed commenting out this line, as I'm worried that the changed ownership may end up in unexpected behaviour at some other point. Since the backup completes, then the main concern is during restoring the backup. Is it possible to tell if a backup created with the line above commented out can be considered reliable? For now, while there is still this doubt, I consider that it is safer to create the backup on a temporary directory and then move the backup files to the target directory manually. Regards, Alexandros
(In reply to Alexandros Panagiotou from comment #4) > Hello, > I am in the process of creating a KCS article for this BZ. I understand that > the chown that fails: > > FileUtils.chown(nil, 'postgres', @dir) > > is trying to change the ownership of the directory to the database group. To > me it seems unsafe to proceed commenting out this line, as I'm worried that > the changed ownership may end up in unexpected behaviour at some other > point. Since the backup completes, then the main concern is during restoring > the backup. Is it possible to tell if a backup created with the line above > commented out can be considered reliable? > > For now, while there is still this doubt, I consider that it is safer to > create the backup on a temporary directory and then move the backup files to > the target directory manually. > > Regards, > Alexandros Changing the ownership will be required to backup the postgres database while doing an online backup. A temporary workaround could be either to change the chmod command from 0770 to 0777, or to do an offline backup. This BZ is one of the next in my queue, so there will be a longer term solution coming up soon.
Hi, First of all thanks for confirming what the side-effects of the chown can be. I just want to make sure we are on the same page here. The workaround is: [1] Comment out the chown (as this will fail if not commented out) [2] Change chmod from 0770 to 0777 or do an offline backup. What puzzles me, is that both in the case of the reproducer and in the case of the customer, the backup succeeds without the additional change of the chmod (i.e. removing chown allows katello-backup to finish) Regards, Alexandros
(In reply to Alexandros Panagiotou from comment #6) > Hi, > First of all thanks for confirming what the side-effects of the chown can > be. I just want to make sure we are on the same page here. The workaround is: > > [1] Comment out the chown (as this will fail if not commented out) > > [2] Change chmod from 0770 to 0777 or do an offline backup. > > What puzzles me, is that both in the case of the reproducer and in the case > of the customer, the backup succeeds without the additional change of the > chmod (i.e. removing chown allows katello-backup to finish) > > Regards, > Alexandros It is my understanding that the restoration will fail; however, I am going to verify this information with Chris Roberts.
I agree with Christine on this will fail, the workaround is to use the chmod command from 0770 to 0777, or to do an offline backup. You could also do a chgrp to postgres which would keep the owner as root.
* But allow postgres to write to the dir
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days