Re: [Spacewalk-devel] Remove audit review cruft from spacewalk-setup
On 03/31/2010 03:17 AM, Jan Pazdziora wrote: The problem is: traditionally, /var/satellite as the default values of the mount point was never maintained by the rpm database. There are use cases where people mount the /var/satellite over NFS or share among Satellites, etc. By now putting the rpm-managed /var/satellite/systemlogs directory there, I fear we might experience bad side-effects. I'm not opposed to having the directory for systemlogs rpm-managed, I'd just like it to be different directory than something withing the default mount point path. Maybe /var/spacewalk or /var/rhn or something similar? OK- that sounds good. I'll write up a patch tomorrow or Friday to move it over. It will probably be something like /var/spacewalk/systemlogs. Do you have any recommendations on how to handle upgrades? Some options: - just make a release note about it, nothing else - have a %post script move the directory (gross!) - drop a line in rhn.conf pointing the audit code to /var/satellite/systemlogs from a %post - have the code look in both (also gross) Thanks, Josh smime.p7s Description: S/MIME Cryptographic Signature ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] API script contributions
Hi, I've written a few python scripts in the past against the Satellite/Spacewalk API, and I was hoping I could have them put into the contrib repo as examples for other people. The three scripts I've written are: http://people.redhat.com/bholden/scripts/merge-errata-to-channel/ http://people.redhat.com/bholden/scripts/misc-satellite-scripts/satserver-listmachines.py http://people.redhat.com/bholden/scripts/create-release/ The merge-errata and create-release scripts both should have READMEs. The function of merge-errata is to take a source and target channel and an end date and patch the target from source upto the date. The create-release script will take in a manifest file with a listing of RPMs and search the Spacewalk server trying to build a channel with those RPMs as its contents. The only one that doesn't have a README is the listmachines reporting script, which logs into the spacewalk server and generates a CSV report of machines managed. Hopefully these are of use to someone. -brent ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: channel.software.listChildren API call
Hi Tomas
Thank you for your comments. I have re-implemented this API call
using ChannelFactory.getAccessibleChildChannels.
CC
On Fri, Mar 26, 2010 at 10:39 PM, Tomas Lestach wrote:
> Hey Colin,
>
> channel.software.listChildren could be useful.
>
> I check your patch and here are my comments:
>
> We already have methods to list child channels. So there's no need to
> implement new ways.
> Just check java/code/src/com/redhat/rhn/domain/channel/ChannelFactory.java for
>
> * listAllChildrenForChannel(Channel parent) {
> * getAccessibleChildChannels(Channel baseChannel, User user)
>
> Because the api calls are based on the authenticated user, I'd use the 2nd
> option to list only the accessible channels to the authenticated user.
>
> Regards,
> Tomas
>
> --
> Tomas Lestach
> RHN Satellite Engineering, Red Hat
>
> - "Colin Coe" wrote:
>
>> Hi all
>>
>> Attached is a patch to implement this API call.
>>
>> Comments/criticisms welcome.
>>
>> CC
>>
>> --
>> RHCE#805007969328369
>>
>> ___
>> 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
>
--
RHCE#805007969328369
From 970758ea6bb35d87e90cf73fa6c94cfed9679bd6 Mon Sep 17 00:00:00 2001
From: Colin Coe
Date: Wed, 31 Mar 2010 21:22:17 +0800
Subject: [PATCH] Re-implement channel.software.listChildren
---
.../common/db/datasource/xml/Channel_queries.xml |9 -
.../channel/software/ChannelSoftwareHandler.java |7 ---
.../redhat/rhn/manager/channel/ChannelManager.java | 14 --
3 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Channel_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Channel_queries.xml
index 42a1c7b..b165f76 100644
--- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Channel_queries.xml
+++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Channel_queries.xml
@@ -1172,14 +1172,5 @@ GROUP BY C.id, C.name
-
-
- SELECT DISTINCT id, label
- FROM rhnChannel
- WHERE parent_channel = :cid
- ORDER BY id
-
-
-
diff --git a/java/code/src/com/redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java b/java/code/src/com/redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java
index bf3faa8..7a5d901 100644
--- a/java/code/src/com/redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java
+++ b/java/code/src/com/redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java
@@ -2004,14 +2004,15 @@ public class ChannelSoftwareHandler extends BaseHandler {
*
*/
-public Object[] listChildren(String sessionKey, String channelLabel) {
+public List listChildren(String sessionKey, String channelLabel) {
// Get Logged in user
User loggedInUser = getLoggedInUser(sessionKey);
channelAdminPermCheck(loggedInUser);
Channel chan = lookupChannelByLabel(loggedInUser, channelLabel);
-DataResult dr = ChannelManager.childChannels(chan.getId());
-return dr.toArray();
+//DataResult dr = ChannelFactory.getAccessibleChildChannels(chan, loggedInUser);
+//return dr.toArray();
+return ChannelFactory.getAccessibleChildChannels(chan, loggedInUser);
}
}
diff --git a/java/code/src/com/redhat/rhn/manager/channel/ChannelManager.java b/java/code/src/com/redhat/rhn/manager/channel/ChannelManager.java
index f191786..66a51ee 100644
--- a/java/code/src/com/redhat/rhn/manager/channel/ChannelManager.java
+++ b/java/code/src/com/redhat/rhn/manager/channel/ChannelManager.java
@@ -2813,18 +2813,4 @@ public class ChannelManager extends BaseManager {
return logPath + possibleList.get(possibleList.size() - 1);
}
-/**
- * Returns a DataResult containing maps representing the child channels of a
- * particular channel.
- * @param channelId The server in question.
- * @return Returns a DataResult of maps representing the child channels a
- * particular channel.
- */
-public static DataResult childChannels(Long channelId) {
-Map params = new HashMap();
-params.put("cid", channelId);
-SelectMode m = ModeFactory.getMode("Channel_queries", "child_channels_of_channel", Map.class);
-return m.execute(params);
-}
-
}
--
1.5.5.6
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Remove audit review cruft from spacewalk-setup
On Tue, Mar 30, 2010 at 08:29:45AM -0400, Joshua Roys wrote: > > The main purpose of the systemlogs directory is to contain various > logs from systems (namely the audit.log files) and the > audit-review.log record-keeping file. I decided yesterday to have > the default be /var/satellite/systemlogs irrespective of the > 'mount_point' variable. The two reasons behind this are: > - the AuditManager class uses a different variable, > web.audit.logdir, to find the systemlogs directory. > - when users would paste their spacewalk-setup output for help on > spacewalk-list, I kept seeing chown errors; the directory /needs/ to > be owned by tomcat now, and if spacewalk-setup made the directory > but failed the chown, the audit code wouldn't be happy without > manual intervention. > > This way, it can be assumed that everything is setup as needed- > although moving the systemlogs directory would require a bit of > knowledge at this point. Two things come out of this: first, I > should probably write an spacewalk-audit-setup script, or somesuch, > to facilitate moving the directory around and setting up various > things. Secondly, and more long-term, I think it would be nice to > have the audit records optionally be in the database (I say > optionally because of the 4G limit of XE - but hopefully the psql > port will eventually take care of that). > > What do you think? Do you agree? Or was it better how it was before? The problem is: traditionally, /var/satellite as the default values of the mount point was never maintained by the rpm database. There are use cases where people mount the /var/satellite over NFS or share among Satellites, etc. By now putting the rpm-managed /var/satellite/systemlogs directory there, I fear we might experience bad side-effects. I'm not opposed to having the directory for systemlogs rpm-managed, I'd just like it to be different directory than something withing the default mount point path. Maybe /var/spacewalk or /var/rhn or something similar? -- 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
