On Friday 27 March 2009 13:28:57 Devan Goodwin wrote:
> On Wed, 25 Mar 2009 13:00:37 -0300
>
> Devan Goodwin <[email protected]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > dgilmore fixed up our jabber configs to work on 2.2 yesterday, so
> > updated spacewalk-config and spacewalk-setup packages correct this,
> > but you probably need to be on a fresh system before it will work.
> > (i.e. not a system where you tried and failed to setup spacewalk, not
> > sure why but Dennis can probably clarify)
> >
> > Issue found and fixed this morning with regexps in ssl.conf that was
> > causing httpd to refuse to start, Milan fixed up and rebuilt
> > spacewalk-setup-0.5.25.
> >
> > spacewalk-backend also rebuilt this morning to pickup the rhnpush fix
> > jbowes submitted.
> >
> > These should all be appearing in the devel repo soon, I think we
> > updated it 4x daily.
> >
> > On Fedora 10 I see two issues,
> >
> > spacewalk-setup still hangs at the end restarting services. Everything
> > seems to be up and running fine including jabberd, I think the problem
> > is jabberd printing something to stdout/stderr that's messing with the
> > way we intercept output and log it to rhn-installation.log. If you
> > switch to another terminal and run service jabberd restart,
> > spacewalk-setup immediately picks back up and completes. If you trace
> > this down I believe you land in Setup.pm sub system_debug:
> >
> >       while (<PROCESS_OUT>) {
> >           print LOGFILE $_;
> >       }
> >       waitpid($pid, 0);
> >
> > IIRC you never get past the waidpid. It is noteworthy that everything
> > is up and running at this point, spacewalk-setup just doesn't realize
> > it.
> >
> > There's also a lesser problem causing these lines to be printed during
> > spacewalk-setup:
> >
> > Use of uninitialized value $uid in chown
> > at /usr/bin/rhn-generate-pem.pl line 74.
> > Use of uninitialized value $gid in chown
> > at /usr/bin/rhn-generate-pem.pl line 74.
> >
> > This is because we try to change permissions on a file to be owned by
> > the jabberd user, which doesn't exist at least on F10, it's now just
> > the "jabber" user.
> >
> > Devan
>
> One new problem arose yesterday with the ssl cert rpms we build and
> install during spacewalk setup conflicting on
> the /etc/jabberd/server.pem file. This one appears to only be surfacing
> on el5. We suspect the problem is in rhn_ssl_tool.py on this line:
>
> "/etc/jabberd/server.pem:0600,jabberd,jabberd=%s"
>
> The cert location is now in /etc/pki/spacewalk, the jabberd user is also
> wrong as this is just "jabber" with newer jabber rpms.

Of course, when upgrading from earlier version of Spacewalk to 0.5,
hitting this problem is pretty much unavoidable: your
rhn-org-https-ssl-key-pair from previous installation owns 
/etc/jabberd/server.pem which is also owned by jabberd-2.2.5-1
(the new version of jabberd that yum upgrade tries to upgrade to)
and the whole yum upgrade fails (that said, Spacewalk 0.5 is not
upgradeable at the moment).

-Milan

_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to