Re: [Spacewalk-devel] Fwd: Re: [Spacewalk-list] Optimizing postgresql with Spacewalk 1.5 on CentOS 6.0 x86_64
Cliff Perry writes: > So, do we have enough postgreSQL DBA skills to understand what is going > on. Maybe recommend some form of auto vacuum ? or other things for > postgreSQL usage. Hmm, well, the initial post in that thread is mostly misinformation; that poster apparently thinks that removing the comment '#' from a comment documenting a default setting will cause the setting to become something other than the default. The suggestion that made the most sense to me was that transactions were being left open over long periods, preventing autovacuum from cleaning up recently-dead rows. However, that's not much more than speculation at this point. Has anyone got a database that's exhibiting the problem that I could look at? Or some reasonably painless instructions for setting up an instance? It's been some time since I did anything with spacewalk ... regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] "1", "y", "true", "yes", "on" etc
On 09/12/2011 12:17 PM, Miroslav Suchý wrote: Well it is always good to understand more languages. And I know from my experience that people do not always know whether they should use true/yes/1 as different projects use different constants. Sure, because they don't know what is supported from the pile of any possible options. If they would know that there are only 1 and 0, they would get it instantly. So when I have time I try to write code which understood all possible constants. When I'm lazy I just choose one. And it results to a problem, because the config file is not just read by a Spacewalk, but also by a peripheral software and other scripts that does some additional stuff. So instead to write simple stuff, now everyone should support an array of who-knows-what options. I think this is not right. Besides, I would also argue about /etc/rhn/default/* existence that is *meant* to be edited according to FHS[1], while Spacewalk says "Do not do this". Actually entire rhn is in the wrong place inside the /etc directory, because it should be /etc/opt/rhn/... actually. :) Since our configuration files are well documented (hmm not documented, but has all option and its default values) I will not object agains #2, but I think #1 is better. OK, since you do not object against #2, I am going to provide the patch that basically standardizes the whole thing to just 1 or 0 and also saves your free time for something else. :-) ___ 1. http://www.pathname.com/fhs/pub/fhs-2.3.pdf ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - BZ#737697 rhn_check fails to deploy some files when the configuration channel have some other files which does not have a valid UID/GID
On Fri, Sep 23, 2011 at 12:09:39PM -0300, Marcelo Moreira de Mello wrote: > > Yes. rhncfg-client get complains and print into the screen the files which > were not able to be deployed. Although, we can see a lot of sysadmin using > the rhncfg-client get at %post section in their kickstart, where they will > not be able to see such warning too. In this case per example, we have a > customer which expects that rhn_check works deploying half of files, but I do > agree with you that in some other cases, we don't want the machine to be > left in an inconsistent state. > > I think that we can offer to the users an option to make such behavior with a > tunable parameter. Per example, we can add a new option at > rhn-actions-control --enable-half-deploy or --enable-unbatch which turns > rhn_check able to perform unbatched deployments. Please, check the comment > https://bugzilla.redhat.com/show_bug.cgi?id=737698#c1 regarding the > customer's expectations. > > What do you think? My preference would be to keep the current rhn_check (strict) behaviour and change the rhncfg-client get behaviour to - default to the current behaviour on terminal and to strict behaviour of stdout is not a terminal; - have command-line option to force either the strict or non-strict behaviour. -- 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] Audit Log Keeper
Hi! Previously announced attempts to do the auditing in a Spacewalk are now physically real and already working for our SUSE Manager. Currently this is an initial implementation and will do have more options, like use AMQP delivery, will run on something better than just embedded Web Server and so on. You can see the source code of our approach for auditing here: https://github.com/SUSE/auditlog-keeper And you also can get the idea how to use that stuff here: http://wiki.novell.com/index.php/AuditLogKeeper Have a nice weekend. :) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Beware of programmers that carry screwdrivers ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - BZ#737697 rhn_check fails to deploy some files when the configuration channel have some other files which does not have a valid UID/GID
On Sep 22, 2011, at 2:05 PM, Jan Pazdziora wrote: > On Thu, Sep 22, 2011 at 01:02:44PM -0300, Marcelo Moreira de Mello wrote: >> >> When scheduling a config files deployment using the webUI, rhn_check fails >> if some file scheduled does not have a valid UID/GID into client box. >> > > With current unpatched code, when this happens -- are some of the > files deployed and some not, or is the whole deployment cancelled? > I am not completely sure it is correct to deploy half of the files > and not deploy the other half -- especially with the batch-oriented > processing of scheduled actions, you don't want the machine to be > left in an inconsistent state. At unpatched code, the whole deployment is cancelled. It rollbacks all the files and none files is deployed. When I started looking into this issue, I had the thinking that you. > >> This patch introduce to rhn_check the same behavior as rhncfg-client get >> allowing the correct files (which have a valid UID/GID) to be deployed and >> fails to those files which misses a valid UID/GID. >> > > I assume that rhncfg-client get complains loudly about the files it > failed to deploy. From this point of view, it is tolerable that > rhncfg-client get would only deploy half of the files because there > is likely person running that command which would be able to respond > accordingly. Yes. rhncfg-client get complains and print into the screen the files which were not able to be deployed. Although, we can see a lot of sysadmin using the rhncfg-client get at %post section in their kickstart, where they will not be able to see such warning too. In this case per example, we have a customer which expects that rhn_check works deploying half of files, but I do agree with you that in some other cases, we don't want the machine to be left in an inconsistent state. I think that we can offer to the users an option to make such behavior with a tunable parameter. Per example, we can add a new option at rhn-actions-control --enable-half-deploy or --enable-unbatch which turns rhn_check able to perform unbatched deployments. Please, check the comment https://bugzilla.redhat.com/show_bug.cgi?id=737698#c1 regarding the customer's expectations. What do you think? Appreciate your help. Best Regards, mmello > > -- > 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
Re: [Spacewalk-devel] Fwd: Re: [Spacewalk-list] Optimizing postgresql with Spacewalk 1.5 on CentOS 6.0 x86_64
Am 23.09.2011 15:49, schrieb Cliff Perry: So, do we have enough postgreSQL DBA skills to understand what is going on. Maybe recommend some form of auto vacuum ? or other things for postgreSQL usage. I don't know wether I do have enough understanding. However, I found the import bottleneck and know that you really *need* autovacuum enabled and have to fix the dangling transactions (see #705935) so autovacuum starts to improve the situation. For what you want when you import lots of stuff is - cancel your import - stop spacewalk - run a full vacuum on your spacewalk database - start spacewalk - continue your import The import itself leaks dead rows in rhnchannelnewestpackage because the dangling transactions make it impossible for vaccuum to reclaim the dead rows and those are created by every call to rhn_channel.refresh_newest_package Regards, Andreas -- Solvention Ltd. & Co. KG Egermannstr. 6-8 53359 Rheinbach Tel: +49 2226 158179-0 Fax: +49 2226 158179-9 http://www.solvention.de mailto:i...@solvention.de ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: Re: [Spacewalk-list] Optimizing postgresql with Spacewalk 1.5 on CentOS 6.0 x86_64
So, do we have enough postgreSQL DBA skills to understand what is going on. Maybe recommend some form of auto vacuum ? or other things for postgreSQL usage. Cliff Original Message Subject: Re: [Spacewalk-list] Optimizing postgresql with Spacewalk 1.5 on CentOS 6.0 x86_64 Date: Fri, 23 Sep 2011 10:57:13 +0200 From: Michael Mraka Reply-To: spacewalk-l...@redhat.com To: spacewalk-l...@redhat.com Gerald wrote: % Hi, % % I'm now syncing for TWO AND A HALF WEEK (spacewalk-repo-sync for centos5+6 % repos) % and still not finished (spacewalk 1.5 with postgresql, centos5 x86_64). % % Especially the larger repos from rpmforge are a massive problem. % With oracle guess I synced all in max. 2 days. % % I've tried the performance settings from below, tried others, added more % ram, etc. but it still takes ages % % (at the moment I'm syncing package 6200 of 8215 and it takes 61sec per % package! In the beginning it's a bit faster and then % it gets slower and slower). % % Disabling taskomatic and osa-dispatcher didn't help either. Maybe there are % some other suggestions to try? % % Hope someone can speed up this process. Don't postgresql restart help you? http://www.redhat.com/archives/spacewalk-list/2011-September/msg00041.html Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ 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
