So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote:
Comments?
One comment just made on IRC by G:
<G> f13: can't be allow masher to sudo to ftpsync and run a sync command?
We would have to allow masher to sudo with no password in order to run the rsync command. I'm not sure how far we can narrow it down since the rsync source changes each day, only the dest (and other options) remain the same.
On Wed, 2008-08-27 at 21:52 -0700, Jesse Keating wrote:
On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote:
Comments?
One comment just made on IRC by G:
<G> f13: can't be allow masher to sudo to ftpsync and run a sync command?
G = $me :)
We would have to allow masher to sudo with no password in order to run the rsync command. I'm not sure how far we can narrow it down since the rsync source changes each day, only the dest (and other options) remain the same.
Why not something like:
sudo /usr/local/bin/rawhideftpsync.sh <random bit> that runs: rsync ...<normal path>.<random bit> ...
Just a thought.
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Thu, 2008-08-28 at 16:55 +1200, Nigel Jones wrote:
Why not something like:
sudo /usr/local/bin/rawhideftpsync.sh <random bit> that runs: rsync ...<normal path>.<random bit> ...
I think I'd rather not have yet another script to puppet manage and such, so if we could just maybe allow rsync it might be fine.
I just noticed we're going to have to do the same to allow it to do mail as the rawhide user (or somebody is going to have to tell me how to set the From address to something else when calling /bin/mail).
2008/8/28 Jesse Keating jkeating@redhat.com
On Thu, 2008-08-28 at 16:55 +1200, Nigel Jones wrote:
Why not something like:
sudo /usr/local/bin/rawhideftpsync.sh <random bit> that runs: rsync ...<normal path>.<random bit> ...
I think I'd rather not have yet another script to puppet manage and such, so if we could just maybe allow rsync it might be fine.
as nigel said, just allow masher to only sudo su - ftpsync from sudoer or to just rsync the specific dir
I just noticed we're going to have to do the same to allow it to do mail
as the rawhide user (or somebody is going to have to tell me how to set the From address to something else when calling /bin/mail).
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote:
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
Looks like that's not working in EL5. Pitty.
On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote:
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote:
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
Looks like that's not working in EL5. Pitty.
a simple python script to do that is easy enough.
-sv
On Thu, Aug 28, 2008 at 11:27 AM, Seth Vidal skvidal@fedoraproject.org wrote:
On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote:
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote:
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
Looks like that's not working in EL5. Pitty.
a simple python script to do that is easy enough.
Looks like configs/system/sendmail-unicode.py is already out there...
On Thu August 28 2008, Jesse Keating wrote:
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote:
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
Looks like that's not working in EL5. Pitty.
This works for me on CentOS 5, after the "--" sendmail options can be used:
/bin/mail -s SUBJECT to@example.com -- -f from@example.com -F "freeform from part"
Regards, Till
On Thu, 2008-08-28 at 18:38 +0200, Till Maas wrote:
/bin/mail -s SUBJECT to@example.com -- -f from@example.com -F "freeform from part"
Ah, that was the missing part. Thanks. I've tossed in git, will tag it once the current run is done.
2008/8/28 Jesse Keating jkeating@redhat.com
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote:
yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;)
Looks like that's not working in EL5. Pitty.
hm... is installed rhel-5.2 working with mailx-8.1.1 on the box ?
if so, that will imply to update it. This feature has been integrated from release 9.25
another way could be to add ~r From-adress in the header of the file content (should work for version =< 10.2 ).
Nigel Jones wrote:
On Wed, 2008-08-27 at 21:52 -0700, Jesse Keating wrote:
On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote:
Comments?
One comment just made on IRC by G:
<G> f13: can't be allow masher to sudo to ftpsync and run a sync command?
G = $me :)
We would have to allow masher to sudo with no password in order to run the rsync command. I'm not sure how far we can narrow it down since the rsync source changes each day, only the dest (and other options) remain the same.
Why not something like:
sudo /usr/local/bin/rawhideftpsync.sh <random bit> that runs: rsync ...<normal path>.<random bit> ...
Just a thought.
You could configure sudoers to allow the masher user to only be able to execute whatever it sudo's as the ftpsync user:
masher hostname.domain.tld=(ftpsync) NOPASSWD: rsync $rsync_opts foo.<wildcardmatch-source> bar
Does that narrow it down sufficiently?
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, 2008-08-28 at 11:57 +0200, Jeroen van Meeuwen wrote:
You could configure sudoers to allow the masher user to only be able to execute whatever it sudo's as the ftpsync user:
masher hostname.domain.tld=(ftpsync) NOPASSWD: rsync $rsync_opts foo.<wildcardmatch-source> bar
Does that narrow it down sufficiently?
I think so. I'll play with this some today.
On Wed, 27 Aug 2008, Jesse Keating wrote:
So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
Fine by me. ftpsync isn't really one of ours anyway :)
-Mike
On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote:
On Wed, 27 Aug 2008, Jesse Keating wrote:
So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
Fine by me. ftpsync isn't really one of ours anyway :)
it and masher are, however, names that need to get added to the banlist in fas, I think.
-sv
On Thu, 28 Aug 2008, Seth Vidal wrote:
On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote:
On Wed, 27 Aug 2008, Jesse Keating wrote:
So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
Fine by me. ftpsync isn't really one of ours anyway :)
it and masher are, however, names that need to get added to the banlist in fas, I think.
Anyone care to think of a less manual way of doing this?
-Mike
Jesse Keating (jkeating@redhat.com) said:
So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors?
Bill
On Thu, 28 Aug 2008, Bill Nottingham wrote:
Jesse Keating (jkeating@redhat.com) said:
So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there.
For now, I'm syncing rawhide by hand.
Comments?
Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors?
Only if we change the uid of ftpsync. If we change the uid of masher we're good on the mirrors.
-Mike
On Thu, 2008-08-28 at 14:58 -0500, Mike McGrath wrote:
Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors?
Only if we change the uid of ftpsync. If we change the uid of masher we're good on the mirrors.
I went the sudo route. I was able to narrow the command down considerably for safety.
On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote:
We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this.
Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be publicly documented anywhere - beyond the basics) so it's likely that the mounts in question simply don't do ACLs right or you'd have already discussed it...but for the sake of mentioning it, you could just add an additional ACL onto the /pub/fedora directory writeable by master.
Jon.
On Fri, 2008-08-29 at 02:25 -0400, Jon Masters wrote:
Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be publicly documented anywhere - beyond the basics) so it's likely that the mounts in question simply don't do ACLs right or you'd have already discussed it...but for the sake of mentioning it, you could just add an additional ACL onto the /pub/fedora directory writeable by master.
s/master/masher/
(too used to typing "Masters" when I start typing those letters)
Jon.
infrastructure@lists.fedoraproject.org
-
Bill Nottingham -
Jeffrey Ollie -
Jeroen van Meeuwen -
Jesse Keating -
Jesse Keating -
Jon Masters -
Mike McGrath -
Nigel Jones -
Seth Vidal -
Till Maas -
Xavier Lamien