Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-12 Thread Pierre Casenove
Switching to the correct list.
OK, I'll modify the script to try to find /etc/init.d/postgresql OR
/etc/systemd/postgresql.service.
And then, I let "service" to the job!
Thanks for the tips on systemd and see you on monday for the updated patch.

Pierre


2011/11/12 Miroslav Suchy 

>
>
> - Original Message -
> > 3) I'll try to find the best way to detect if systemd is used or not.
> > I don't have a F16 box, so a few questions:
> > - How is postgresql controlled with systemd: postgresql start and
> > stop?
>
> old "service postgresql XXX" still works, it is translated to "systemctl
> XXX postgresql.service", which is native for systemd.
>
> > - Is postgresql the only software that is integrated with systemd in
> > spacewalk?
>
> Probably yes (I'm not sure about httpd). But we use command "service",
> which works for both old sys-v scripts and for systemd too.
> I recommend you the same.
>
>
> Mirek
>
> ___
> Spacewalk-list mailing list
> spacewalk-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-12 Thread Miroslav Suchy
- Original Message -
> 
> Switching to the correct list.
> OK, I'll modify the script to try to find /etc/init.d/postgresql OR
> /etc/systemd/postgresql.service.
> And then, I let "service" to the job!
> Thanks for the tips on systemd and see you on monday for the updated
> patch.

FYI:
# chkconfig postgresql on
Note: Forwarding request to 'systemctl enable postgresql.service'.
ln -s '/lib/systemd/system/postgresql.service' 
'/etc/systemd/system/multi-user.target.wants/postgresql.service'

So presence of /etc/systemd/postgresql.service means just that 
postgresql-server is installed. It does not mean, that it is enabled!
And do not forget that I can have installed (I'm weird men) postgresql and 
oracle, but spacewalk will use only one of them.

Some hints:
# chkconfig postgresql
Note: Forwarding request to 'systemctl is-enabled postgresql.service'.
enabled
# echo $?
0
# LC_ALL=C chkconfig postgresql off
Note: Forwarding request to 'systemctl disable postgresql.service'.
rm '/etc/systemd/system/multi-user.target.wants/postgresql.service'
# LC_ALL=C chkconfig postgresql
Note: Forwarding request to 'systemctl is-enabled postgresql.service'.
disabled
# echo $?
1

Hopes, this will help you.

Mirek

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-12 Thread Pierre Casenove
Thanks a lot for your help and hints.
I'll parse rhn.conf file to find the correct db (db_backend). For
postgresql real activation, I'll do some tests on my server and use your
outputs.

pierre


2011/11/12 Miroslav Suchy 

> - Original Message -
> >
> > Switching to the correct list.
> > OK, I'll modify the script to try to find /etc/init.d/postgresql OR
> > /etc/systemd/postgresql.service.
> > And then, I let "service" to the job!
> > Thanks for the tips on systemd and see you on monday for the updated
> > patch.
>
> FYI:
> # chkconfig postgresql on
> Note: Forwarding request to 'systemctl enable postgresql.service'.
> ln -s '/lib/systemd/system/postgresql.service'
> '/etc/systemd/system/multi-user.target.wants/postgresql.service'
>
> So presence of /etc/systemd/postgresql.service means just that
> postgresql-server is installed. It does not mean, that it is enabled!
> And do not forget that I can have installed (I'm weird men) postgresql and
> oracle, but spacewalk will use only one of them.
>
> Some hints:
> # chkconfig postgresql
> Note: Forwarding request to 'systemctl is-enabled postgresql.service'.
> enabled
> # echo $?
> 0
> # LC_ALL=C chkconfig postgresql off
> Note: Forwarding request to 'systemctl disable postgresql.service'.
> rm '/etc/systemd/system/multi-user.target.wants/postgresql.service'
> # LC_ALL=C chkconfig postgresql
> Note: Forwarding request to 'systemctl is-enabled postgresql.service'.
> disabled
> # echo $?
> 1
>
> Hopes, this will help you.
>
> Mirek
>
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
>
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-12 Thread Miroslav Suchy
- Original Message -
> I'm against this change. The database (PostgreSQL, Oracle XE) is
> completely independent from the Spacewalk software product and the
> spacewalk-service script should have no business fiddling with them.

Define "completely independent". It is not true. Spacewalk use it. As it use 
apache.
And tomcat. And jabber.

Pierre is not first one, who wanted this feature, and will not be the last one.
I - personally - would not spent my devel cycles on it, but Pierre is willing
to do that and contribute it.
 
We recommend to run Spacewalk on dedicated machine. And I suppose that most 
users
obey this recommendation. So if there is DB instance, it is very likely 
dedicated
to Spacewalk.
But yes, it can be used for other purposes as well. For that reason, I wanted to
have this option disabled by default. So current behavior will be preserved.
 
> If for some reason (what reason, exactly?) you need to restart
> everything with one script, why not write a wrapper around it?

As I said, more user already wanted it. And it is much easier and better for 
users 
to code this wrapper once, and leave dozen admins to flip one variable as 
compared
to leave dozens admins to write theirs wrapper.

You can easily say, why we have spacewalk-repo-sync, when everybody can write 
wrapper
around rhnpush? Well - it make life much easier.

Mirek



___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-13 Thread Jan Pazdziora
On Sat, Nov 12, 2011 at 09:52:07PM +0100, Pierre Casenove wrote:
> Ok no problem, no patch so. If you're against it, I won't insist!
> Just to answer your email : HTTPD is also quite independant from the
> spacewalk product and still, it is controlled. And if postgresql gets

It is not as independent as we'd like -- we use mod_wsgi/mod_perl, so
for example an upgrade of Spacewalk requires restart of httpd.

On the other hand, even upgrade of Spacewalk's database schema does not
require restart of the underlying database server.

> restarted with SP up and running, spacewalk needs also to be restarted
> (connection is lost and never gets restored)

This would be a bug, it should be reported as such, investigated and
fixed.

On Sat, Nov 12, 2011 at 04:54:48PM -0500, Miroslav Suchy wrote:
> - Original Message -
> > I'm against this change. The database (PostgreSQL, Oracle XE) is
> > completely independent from the Spacewalk software product and the
> > spacewalk-service script should have no business fiddling with them.
> 
> Define "completely independent". It is not true. Spacewalk use it. As it use 
> apache.
> And tomcat. And jabber.

That's true, Spacewalk uses the database. But the database server is
like filesystem or network for Spacewalk. No action of the Spacewalk
application (not even its upgrade) requires restart of the database.
Unlike apache, tomcat, and (presumably) jabberd -- we modify the
configuration of apache, tomcat, and jabberd for Spacewalk to work
correctly, and for that we need to restart those services.

> I - personally - would not spent my devel cycles on it, but Pierre is willing
> to do that and contribute it.
>
> We recommend to run Spacewalk on dedicated machine. And I suppose that most 
> users
> obey this recommendation. So if there is DB instance, it is very likely 
> dedicated
> to Spacewalk.
> But yes, it can be used for other purposes as well. For that reason, I wanted 
> to
> have this option disabled by default. So current behavior will be preserved.

[...]

> As I said, more user already wanted it. And it is much easier and better for 
> users 
> to code this wrapper once, and leave dozen admins to flip one variable as 
> compared
> to leave dozens admins to write theirs wrapper.

The problem is -- it is likely to become maintenance burden in the
long run. Noone but few people will use it because the default will
be to have the option off, therefore we won't be testing it.

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] [Spacewalk-list] Modification of spacewalk-service script

2011-11-13 Thread Pierre Casenove
Let's forget the subject, no problem. I share Miroslav point of view, but
understand yours. And you're right, it'll surely be a maintenance burden.
I'll investigate on database reconnection problem only.
I just wanted to help, you know!
By the way, I couldn't get rid of osa-distpatcher error message connecting
to jabber, which was the beginning of the discussion!
The problem is that jabberd do listen on the network but is not completely
ready (message "sm not ready" returned by jabberd when connecting). So the
pid file already exists and no test can be done to check if jabberd is
really ready. Calling "sleep 2" was the only way around (even sleep 1
didn't do the trick). From my point of view, as osa-dispatcher reconnects
10 seconds after, the only problem is the message displayed to the user.
But it is better thant calling sleep 2 in the script during startup I think.

Pierre

2011/11/13 Jan Pazdziora 

> On Sat, Nov 12, 2011 at 09:52:07PM +0100, Pierre Casenove wrote:
> > Ok no problem, no patch so. If you're against it, I won't insist!
> > Just to answer your email : HTTPD is also quite independant from the
> > spacewalk product and still, it is controlled. And if postgresql gets
>
> It is not as independent as we'd like -- we use mod_wsgi/mod_perl, so
> for example an upgrade of Spacewalk requires restart of httpd.
>
> On the other hand, even upgrade of Spacewalk's database schema does not
> require restart of the underlying database server.
>
> > restarted with SP up and running, spacewalk needs also to be restarted
> > (connection is lost and never gets restored)
>
> This would be a bug, it should be reported as such, investigated and
> fixed.
>
> On Sat, Nov 12, 2011 at 04:54:48PM -0500, Miroslav Suchy wrote:
> > - Original Message -
> > > I'm against this change. The database (PostgreSQL, Oracle XE) is
> > > completely independent from the Spacewalk software product and the
> > > spacewalk-service script should have no business fiddling with them.
> >
> > Define "completely independent". It is not true. Spacewalk use it. As it
> use apache.
> > And tomcat. And jabber.
>
> That's true, Spacewalk uses the database. But the database server is
> like filesystem or network for Spacewalk. No action of the Spacewalk
> application (not even its upgrade) requires restart of the database.
> Unlike apache, tomcat, and (presumably) jabberd -- we modify the
> configuration of apache, tomcat, and jabberd for Spacewalk to work
> correctly, and for that we need to restart those services.
>
> > I - personally - would not spent my devel cycles on it, but Pierre is
> willing
> > to do that and contribute it.
> >
> > We recommend to run Spacewalk on dedicated machine. And I suppose that
> most users
> > obey this recommendation. So if there is DB instance, it is very likely
> dedicated
> > to Spacewalk.
> > But yes, it can be used for other purposes as well. For that reason, I
> wanted to
> > have this option disabled by default. So current behavior will be
> preserved.
>
> [...]
>
> > As I said, more user already wanted it. And it is much easier and better
> for users
> > to code this wrapper once, and leave dozen admins to flip one variable
> as compared
> > to leave dozens admins to write theirs wrapper.
>
> The problem is -- it is likely to become maintenance burden in the
> long run. Noone but few people will use it because the default will
> be to have the option off, therefore we won't be testing it.
>
> --
> Jan Pazdziora
> Principal Software Engineer, Satellite Engineering, Red Hat
>
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
>
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel