Bug 479556
Summary: | Mock don't build anything | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Frank Büttner <bugzilla> | ||||
Component: | mock | Assignee: | Clark Williams <williams> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | low | ||||||
Version: | el5 | CC: | bugzilla, dcantrell, fedora, mail2benny, mastahnke, mebrown, opensource, tremble, williams | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | ActualBug | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-05-08 15:27:59 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 449396, 503158, 548713, 557424 | ||||||
Attachments: |
|
Description
Frank Büttner
2009-01-11 09:02:25 UTC
Try passing mock -v -r <distname> --rebuild <srpm> this will result only in this: [frank@homer EL-5]$ mock -v -r epel-5-i386 --rebuild qwt-5.0.2-5.el5.src.rpm [frank@homer EL-5]$ If you use mock-0.9.14-1.el5 do you still have this issue? Yes it is mock-0.9.14-1.el5. first, try adding --verbose to the command line: $ mock --verbose -r distname --rebuild qtiplog-0.9.7.4-8.fc11.src.rpm if you still don't get any output, please attach your srpm (or post a link where we can download it) so we can debug with the actual srpm. oh, another thing: have you tried building any other srpm? if you can't build anything, then it's something specific to your setup, whereas if you can't build just the qtiplot srpm, then we need to look there. [frank@homer devel]$ mock --verbose -r epel-5-i386 --rebuild qtiplot-0.9.7.4-8.fc11.src.rpm [frank@homer devel]$ this is all output. Yes it will happend with all srpm's. an simple rpmbuild --rebuild will do it's job. But not mock without any error. I have tested it with other targets all the same. The fact that you're not getting *any* output means something fundamental is going wrong. What do you see when you strace the mock command? $ strace mock --verbose -r epel-5-i386 --rebuild <some srpm> Created attachment 351069 [details]
The stacktrace output.
I hope this will help. well, it's certainly interesting. It's definitely something about the way your system is set up. The last part of the strace is where things go wrong. When mock runs, it really runs the 'consolehelper' application to verify that you have permissions to run mock (i.e. you're either root or in the mock group). The program opens a TCP socket through localhost to port 6010, which is involved with SSH. It writes some magic stuff to the socket, sets the socket to non-blocking and tries to read a response, gets an error on the read and bails out. The reason you're not getting any output is that the process hasn't gotten to the part of starting up python. You may want to look at how you're doing authentication. Hm, I use only a simple SSH session to the build Server. Other python programs will run without any problems. And I am an member of the mock group. Hi Frank, have you tried to: - temporarily set SELinux to permissive mode, somethings file contexts are fscked up; `tail -f /var/log/audit/audit.log` during mock runs? - use a different (dedicated) user for mock builds? - purge /var/{cache,lib}/mock/* and use a vanilla (unmodified) epel-5-i386 mock config file? Are you - using an NFS or Fuse (sshfs etc.) mounted /home (or /var)? Missing flock'ing capabilities can become a serious problem - pre-occupying port 6010 with anything else? For testing I have complete disable selinux. -> same result. No NFS,fuse,cifs etc. home share. The only change at the config file is, that it use an local repo for the RPM files. But use the original will not work. Using the another user for mock: useradd -g users -G mock testmock passwd testmock add user testmock to AllowUser at ssh config. reload sshd demon. log in via ssh as testmock: [testmock@homer ~]$ mock --help [testmock@homer ~]$ same result. Hey Frank, some more ideas: Try enabling/disabling (-X/-x) SSH X11 forwarding. To me the strace output looks like the MIT-MAGIC-COOKIE-1 contents are written to 127.0.0.1:6010 on fd 4, for whatever reasons - almost right after that, when trying to read back from fd 4, mock exits. Do you have direct access to the box running mock, i.e. can you try running mock without any SSH? Here are some commands I would test, whether they work: As User: mock clean -r fedora-12-i386 If it does not work, then as root: /usr/sbin/mock clean -r fedora-12-i386 Can you maybe give a developer shell access to the system to debug this easier? Or can you reproduce the problem using a CentOS Live medium? - Setting "X11Forwarding no" will not change anything. - No, for security reasons you can't get access to the machine. local login will work, but is not workaround because the machine has normality no keyboard+ display. But what is interesting is that(running via ssh): [testmock@homer ~]$ /usr/sbin/mock --help ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. [testmock@homer ~]$ /usr/bin/mock --help [testmock@homer ~]$ Well mock ought to be run by a user with group membership mock and through consolehelper (symlink /usr/bin/mock -> consolehelper) so directly running /usr/sbin/mock is not what you want anyway (the error message is correct here).
/etc/security/console.apps/mock defines the rules for running the actual mock binary through consolehelper.
Can you please try to comment out
>session optional pam_xauth.so<
in /etc/pam.d/mock? The X11 part of your strace log still nags me..
(In reply to comment #17) > But what is interesting is that(running via ssh): > > [testmock@homer ~]$ /usr/sbin/mock --help Can you please try to run it as root? It will help to distinguish, whether the problem is in mock or in the consolehelper setup that gives root privs to mock. (In reply to comment #19) > (In reply to comment #17) > > > But what is interesting is that(running via ssh): > > > > [testmock@homer ~]$ /usr/sbin/mock --help > > Can you please try to run it as root? It will help to distinguish, whether the > problem is in mock or in the consolehelper setup that gives root privs to mock. I just thought about it, given that local login works, this will certainly work, so the workaroud is to use sudo instead of consolehelper to run mock. comment out "session optional pam_xauth.so" don't change something "/usr/sbin/mock --help" will fail with the same error "ERROR: [Errno 1] Operation not permitted" run /usr/sbin/mock --help as root will work. (In reply to comment #21) > comment out "session optional pam_xauth.so" > don't change something "/usr/sbin/mock --help" will fail with the same error > "ERROR: [Errno 1] Operation not permitted" As non root user, you need to run /usr/bin/mock > run /usr/sbin/mock --help as root will work. So you can probably just use "sudo /usr/sbin/mock" to perform mock builds until the userhelper issue is resolved. Afaics, it is not more or less insecure than using userhelper. (It's actually userhelper not consolehelper). I am not an sudoers/userhelper expert, but using this sudoers config: %mock ALL= NOPASSWD: /usr/sbin/mock * and alias mock="sudo /usr/sbin/mock" should emulate the userhelper setup. Btw: I just stumbled upon this in man userhelper: SESSION Specifies whether or not userhelper should perform PAM session management when running the program. Typically this is needed if the PAM configuration uses a module such as pam_xauth.so to forward X11 authentication tokens for use by the program. Valid values are yes and no, with the default being no. And on F12: $ grep SESSION /etc/security/console.apps/mock SESSION=false So probably just using mock already works with the updated pam config. Hello again, I have test the follow: add line "%mock ALL= NOPASSWD: /usr/sbin/mock *" via visudo than log in as testmock via ssh and run: [testmock@homer ~]$ mock="sudo /usr/sbin/mock" [testmock@homer ~]$ mock --help [testmock@homer ~]$ So far I can see, nothing will has changed.:( Or have I misunderstood some think? (In reply to comment #23) > [testmock@homer ~]$ mock="sudo /usr/sbin/mock" This needs to be: alias mock="sudo /usr/sbin/mock" Hello, I have try it. As an workaround it will work. But I think we shut see, what the original problem is. So I don't close the Bug. You can try to set "SESSION=true" or maybe "FALLBACK=true" in /etc/security/console.apps/mock Hello, /etc/security/console.apps/mock contains at me: USER=root PROGRAM=/usr/sbin/mock SESSION=false FALLBACK=false I have revert the visudo change and set SESSION=true FALLBACK=true The result is the same, when call mock via ssh: [testmock@homer ~]$ mock --help [testmock@homer ~]$ Frank, I don't know if this one is still a problem for you, but I saw something very similar last year when setting up a koji-builder instance. What happens if you try "unset DISPLAY" before running mock. Frank, we're now up to mock version 1.0.7 are you able to confirm that this bug is still occurring for you? Additionally if you are could you try unsetting DISPLAY prior to running mock. well, if no one objects, I say we close this one. |