buildsys June 2006

buildsys@lists.fedoraproject.org

20 participants
21 discussions

Start a nNew thread

Extras build system back up
by Dan Williams 26 Oct '06

26 Oct '06

Hi, We're back up and using the latest plague code. yum update your plague-client and you should be good to go. Dan

3 7

mock launcher changes checked into head of CVS
by Clark Williams 28 Jun '06

28 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The branch for mock 0.6 has been cut and my modifications for the new launcher mechanism have been checked into the head of CVS (which is now at 0.7). Please pull the new stuff and beat on it. You'll need to clean up the links in /etc/mock, since there are no fedora-6-* config files yet. Sorry about that... I'm not completely sure I have things right wrt to uid/gid manipulations. I'd appreciate a critical eye being cast on that portion of the code. Michael, I stuffed the flock calls in, around the state file write. Just wanted to see what they'd do and I forgot when I did my check in. Easy enough to back out if we decide they're not needed. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoqsMHyuj/+TTEp0RAp4AAJ94Wu8doF5En6WUFjdfsM5RcAjw+wCdFYMz 8YbPBDQr2+mFyIiySKIJ2sY= =yEDy -----END PGP SIGNATURE-----

1 0

New version of mock working (I think)
by Clark Williams 27 Jun '06

27 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, The inside-out version of mock (or upside-down, depending on your perspective) seems to be working. For those that don't know what I'm talking about, we've been looking at changing the way mock deals with uid/gid manipulation to improve security a bit. The old way was for /usr/bin/mock to be a link to mock.py and whenever mock wanted to do something that required root privilege, it called a setuid root program called /usr/sbin/mock-helper. This program knew how to do a select few commands (chroot, mount, etc.) and did some argument validation. Unfortunately mock-helper has some security issues and extending it would require us to write more C code. While most of us aren't afraid of writing C code, writing *secure* C code is not simple and in this case it's probably not worth the effort. Someone (Michael?) suggested that we turn everything around and write a simple setuid root/setgid mock launcher program that would then start mock.py and allow it to manipulate privilege from python code. I wrote the first cut at a launcher and then added code to mock.py to elevate and drop privileges around commands that needed it. I now have a set of code that will build simple SRPMS (elinks, rsync, tar, etc.) and would like to get some other eyeballs on this code. The "new" organization is we have a /usr/bin/mock that is a setuid C program which only knows how to exec /usr/bin/mock.py. While none of the changes are massive, they are spread across a few files (Makefile, mock.py, mock.spec, etc/default.cfg, src/Makefile, src/mock.c) so I'm wondering if I should just blast out the files to the list, or if I should cut a branch in CVS and let people look at it from there? Or, should I just check it in and if the consensus is that it sucks, we can change or revert? Thoughts? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEmZwMHyuj/+TTEp0RAsyIAJ9Q2p6qo4SDAc+Je8FAg6GvB6KwVACgum1b WZnKm0kdjPFob0k3aQQG8aU= =ry4/ -----END PGP SIGNATURE-----

11 61

Branch mock CVS today?
by Clark Williams 27 Jun '06

27 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I didn't get any reply on my question about CVS manipulation, so I thought I'd start a new thread. The HEAD of mock's CVS tree is currently at v0.6. I'd like to branch that so that we have a safe point to drop back to, before we move to the new launcher, add some file locking or whatever we decide to do for reporting status, etc. To do that, I'm proposing the following in CVS: $ cvs co mock $ cd mock $ cvs tag mock-0-6-branchpoint $ cvs tag -r mock-0-6-branchpoint -b mock-0-6-branch Theoretically, this will create a static tag (the branchpoint tag) and then create a branch named mock-0-6-branch, based on the branchpoint tag. We can then do our wild-and-crazy checkins to head and know that we have a safe haven. I'm not wedded to the names or the methodology (that's just how we tend to manage branches in my group). If no one has any suggestions or objections, I'll branch later this afternoon (US Central time) and we can start putting the new code in and testing. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoWXXHyuj/+TTEp0RAsC8AKCY2nfmuuRtUyXzk01MxWJa6bcUYQCfdYn7 Wg7vMZFDutSFm2K5i+GYSAA= =FXyD -----END PGP SIGNATURE-----

4 6

To xml-rpc or not to xml-rpc. Reporting mock state
by Jesse Keating 27 Jun '06

27 Jun '06

Perhaps I've been a bit overengineering this. Do we really need a full xml-rpc just to report status? After talking to our team, and seeing Mike's post, perhaps dumping to an xml file (with locking) is a saner solution and easier to deal with when wrapping mock up. I don't have any vested interest in any solution, I was just hoping to offer up options. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)

2 1

Default config file contents
by Michael E Brown 26 Jun '06

26 Jun '06

Discussion topic: With the recent changes to mock, several default config file options have changed. I am of the opinion that we should provide a config file with only the basic things that the user would like to change, and leave the defaults in mock.py (with an option to dump the config). For example, I believe we should take out the mount, unmount, rm, chroot, etc from our default configs, as it is highly unlikely that average users would change these. The reason for this proposed change is to make it easier to migrate from one version to the next. As it is, mock 0.7 will not be able to use %config(noreplace) on the config files, because too many things changed. The user will have to manually merge any site-specific changes. The final config file, I believe, should only contain the yum config relating to repository locations, which the user is likely to want to mirror for speed reasons. Comments? -- Michael

3 2

First srpm built with new mock launcher + modified mock.py
by Clark Williams 15 Jun '06

15 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I actually built an SRPM last night, using a moderately hacked mock.py with the new mock launcher. After figuring out what Michael meant wrt uid/gid manipulation, I went into mock.py and added two methods to the Root class: elevate() - change uid to the effective uid (i.e. root) drop() - change uid back to real uid (i.e. your user id) I modified the startup code to save off effective and real uids and to set the realgid to the mock group. I then bracketed calls to "do" that require privileges (e.g. chroot, mount, etc.) to look like this: self.elevate() self.do(<privileged command>) self.drop() I had an elinks srpm hanging around and fired off a mock build of that package, which after finding a couple of calls that needed privileges, worked (I'm always amazed when that happens). Admittedly it's not a complex build, but it's a start. One thing I'm puzzled about is that the build worked on a system running SELinux and currently the SELinux preload isn't being done. Anyone have an example build that bombs because of SELinux when the LD_PRELOAD isn't done? I need to do a little tidying up of mock.py. The cache stuff is completely broken because the actual pack/unpack logic is in the now-defunct mock-helper. I got started moving it into mock.py, but was overcome with sleepiness last night and didn't finish. I'll try and send out a mock.py to the list today (or would you rather have a patch?). Just wanted some eyeballs on it to see if it's going in the right direction. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkWxuHyuj/+TTEp0RAhKNAJ0UNRD78/MRAZPe44ED/CWl8bRongCgwTbR Cmv9TG+KS2JYplFs6R7lVG8= =5hTr -----END PGP SIGNATURE-----

2 2

Noticing something in the output
by Jesse Keating 15 Jun '06

15 Jun '06

Is there a reason we do a yum resolvedeps prior to install? I assume maybe its checking to see if it _can_ resolve the deps, but couldn't we rely upon yum install to error out if we can't resolve them? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)

2 1

First cut a new mock launcher
by Clark Williams 15 Jun '06

15 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is the C source that is my first attempt at a mock launcher program. This program is built as the executable /usr/bin/mock with setuid:root, setgid:mock and will exec python with the input file /usr/bin/mock.py. The program successfully launches python, but I haven't worked through all the issues to complete a build (yet). I know that mock.py needs to be modified to remove the dont-run-as-root test and I've made a first cut at removing mock-helper from .cfg files, but I'm sure there are other things that need to be done. I have checked nothing into CVS at this point and even if/when I do, I suspect I'll be working off a branch for a while. Note that the program makes use of Linux namespaces. This *should* make our handling of mount points within the chroot (/proc, /sys, etc.) a bit easier to clean up, since when the process dies the mounts should just go away. I haven't verified this though, so caveat emptor. Anyway, it's a starting point. Please look it over and provide feedback. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkC9DHyuj/+TTEp0RAq+4AKCn4hj3bGInJBMWd1Bj6h1SMeCV+QCgt3NW hPHE9hW9DXL9ZkPLbaJrL6Y= =XtsC -----END PGP SIGNATURE-----

4 8

Second pass at a mock launcher
by Clark Williams 14 Jun '06

14 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is the second pass after comments from Michael and Mike. - -- removed conditional compile of debugging prints - -- added MOCKDEBUG environment variable to turn on debug prints - -- removed usage() function (allow mock.py to report) - -- removed privilege change code (allow mock.py to manage uid/gid) - -- removed SELinux LD_PRELOAD code (allow mock.py to manage) Again, comments/criticism welcome. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkHxMHyuj/+TTEp0RAnsTAJ4hjY5MWKDsn6cfS6roN33R1wonhQCfdudU WXJaNXSQJ/R5i3F/z/i1fvQ= =nTbj -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys June 2006