Re: [Spacewalk-list] rhnreg_ks on F15
On Wed, Apr 13, 2011 at 22:07, Miroslav Suchy msu...@redhat.com wrote: That is strange. Sandro, can you run this for me: subsystem usb devtype usb_device name usb1 number 1 sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48384 device file: /dev/bus/usb/001/001 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1a.0/usb1 SUBSYSTEM = usb MAJOR = 189 MINOR = 0 DEVNAME = /dev/bus/usb/001/001 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/001/001 PRODUCT = 1d6b/2/206 TYPE = 9/0/0 BUSNUM = 001 DEVNUM = 001 subsystem usb devtype usb_interface name 1-0:1.0 number 0 sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1/1-0:1.0 driver: hub action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_NONE of type GUdevDeviceType device number: 0 device file: None device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1a.0/usb1/1-0:1.0 SUBSYSTEM = usb DEVTYPE = usb_interface DRIVER = hub DEVICE = /proc/bus/usb/001/001 PRODUCT = 1d6b/2/206 TYPE = 9/0/0 INTERFACE = 9/0/0 MODALIAS = usb:v1D6Bp0002d0206dc09dsc00dp00ic09isc00ip00 subsystem usb devtype usb_device name 1-1 number 1 sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1/1-1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48385 device file: /dev/bus/usb/001/002 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1a.0/usb1/1-1 SUBSYSTEM = usb MAJOR = 189 MINOR = 1 DEVNAME = /dev/bus/usb/001/002 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/001/002 PRODUCT = 8087/20/0 TYPE = 9/0/1 BUSNUM = 001 DEVNUM = 002 subsystem usb devtype usb_interface name 1-1:1.0 number 0 sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 driver: hub action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_NONE of type GUdevDeviceType device number: 0 device file: None device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1a.0/usb1/1-1/1-1:1.0 SUBSYSTEM = usb DEVTYPE = usb_interface DRIVER = hub DEVICE = /proc/bus/usb/001/002 PRODUCT = 8087/20/0 TYPE = 9/0/1 INTERFACE = 9/0/0 MODALIAS = usb:v8087p0020ddc09dsc00dp01ic09isc00ip00 subsystem usb devtype usb_device name usb2 number 2 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48512 device file: /dev/bus/usb/002/001 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1d.0/usb2 SUBSYSTEM = usb MAJOR = 189 MINOR = 128 DEVNAME = /dev/bus/usb/002/001 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/002/001 PRODUCT = 1d6b/2/206 TYPE = 9/0/0 BUSNUM = 002 DEVNUM = 001 subsystem usb devtype usb_interface name 2-0:1.0 number 0 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-0:1.0 driver: hub action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_NONE of type GUdevDeviceType device number: 0 device file: None device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1d.0/usb2/2-0:1.0 SUBSYSTEM = usb DEVTYPE = usb_interface DRIVER = hub DEVICE = /proc/bus/usb/002/001 PRODUCT = 1d6b/2/206 TYPE = 9/0/0 INTERFACE = 9/0/0 MODALIAS = usb:v1D6Bp0002d0206dc09dsc00dp00ic09isc00ip00 subsystem usb devtype usb_device name 2-1 number 1 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48513 device file: /dev/bus/usb/002/002 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1d.0/usb2/2-1 SUBSYSTEM = usb MAJOR = 189 MINOR = 129 DEVNAME = /dev/bus/usb/002/002 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/002/002 PRODUCT = 8087/20/0 TYPE = 9/0/1 BUSNUM = 002 DEVNUM = 002 subsystem usb devtype usb_device name 2-1.1 number 1 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48514 device file: /dev/bus/usb/002/003 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1 SUBSYSTEM = usb MAJOR = 189 MINOR = 130 DEVNAME = /dev/bus/usb/002/003 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/002/003 PRODUCT = 557/7000/100 TYPE = 9/0/0 BUSNUM = 002 DEVNUM = 003 subsystem usb devtype usb_device name 2-1.1.1 number 1 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48515 device file: /dev/bus/usb/002/004 device file symlinks: UDEV_LOG = 3
Re: [Spacewalk-list] rhnreg_ks on F15
On 04/14/2011 08:10 AM, Sandro red Mathys wrote: On Wed, Apr 13, 2011 at 22:07, Miroslav Suchy msu...@redhat.com wrote: That is strange. Sandro, can you run this for me: subsystem usb devtype usb_device name usb1 number 1 sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1 driver: usb action: None seqnum: 0 device type: enum G_UDEV_DEVICE_TYPE_CHAR of type GUdevDeviceType device number: 48384 device file: /dev/bus/usb/001/001 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1a.0/usb1 SUBSYSTEM = usb MAJOR = 189 MINOR = 0 DEVNAME = /dev/bus/usb/001/001 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/001/001 PRODUCT = 1d6b/2/206 TYPE = 9/0/0 BUSNUM = 001 DEVNUM = 001 ... Thx. Fixed in commit c118e8287162a70c600210e67b5a814c48db3ef7 -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] OSA problems / Tomcat errors
I have some problems that jobs aren't carried out bij OSA rhn_check works fine. OS: CentOS 5.6 In /var/log/rhn/rhn-dispatcher.log there aren't any faults. In catalina.out there are some errors during startup: SEVERE: ContainerBase.addChild: start: LifecycleException: Error initializaing : java.lang.NullPointerException at org.apache.catalina.core.StandardContext.start(StandardContext.java:3986) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:634) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:561) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:496) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1193) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) Apr 14, 2011 10:21:19 AM org.apache.catalina.startup.HostConfig deployDescriptor SEVERE: Error deploying configuration descriptor rhn.xml java.lang.IllegalStateException: ContainerBase.addChild: start: LifecycleException: Error initializaing : java.lang.NullPointerException at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:764) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:634) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:561) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:496) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1193) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) 2011-04-14 10:21:20,283 [main] ERROR org.apache.catalina.session.ManagerBase - IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: com.redhat.rhn.common.db.datasource.CachedStatement java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: com.redhat.rhn.common.db.datasource.CachedStatement at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) at java.util.ArrayList.readObject(ArrayList.java:696) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown
Re: [Spacewalk-list] Database user data
Anthony Hare wrote: % Does it stop once it hits the 4GB limit or is it a performance hit? Talking about Oracle 10g XE - yes, 4GB (or precisely 5GB for user, sys and undo) is a hard limit and the database will fail to extend tables beyond it. Currently released beta version of Oracle 11g XE has this limit extended to 11GB so you may look forward to stable version :). Or you can use PostgreSQL version which has major features working already. % Did I miss the new more accurate numbers? https://fedorahosted.org/spacewalk/wiki/HowToInstall says: Prerequisites ... * Storage for database: 250 KiB per client system + 500 KiB per channel + 230 KiB per package in channel (i.e. 1.1GiB for channel with 5000 packages) -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] triggering scripts on a client machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello First let me say thanks for all the help in setting up my spacewalk server and client , I am now able to deploy software and scripts to the target server. What I'd like to ask is how can I make spacewalk deploy a file (bash script ) and trigger it to execute ? is that at all possible ? Also is there a way to do a bulk upload of files to spacewalk ? I have about 60+ scripts that I need to upload so a bulk upload will be very handy. Thank you Assaf -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.1.0 (Build 860) Charset: us-ascii wsBVAwUBTaa9xWK6JZrjLX7GAQjsigf+MZU56sb/8q84VtRf8WrZ/3X3HlFZoApE 5NIsmBjjXMQBzDRBrFFCT13Qcjakg6mCl4EfYw1pjGJjgi7bB5fp31HRT0AWvobc eawLxDMOfmyLirHLpkwfZa4wAPsWVMehMSv4aRWLo2edJeet5RJ/0UWWXQbxE9CK OtSa9zbGdiRakJ3hNJJCXs8bSGeIJV5mQnR4b1hSFXlALfE6RgtdXU2xfHyVMbwE dathfqrYDjTAQoLPYCgYqo8Cff9A28DwDTKr1iKmUsfpesrgbRsXIX6v/yCGW2zx gkNvjBw951lLIHIS9vxVmphCJYnxXEPjmKKEdzQfkAmYhmJ/yaG5mw== =P7n6 -END PGP SIGNATURE- ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] ISE While Attempting to Upload GPG Key or Kickstart File
Hello Trevor, thank you for the report. I've fixed the issue. spacewalk-java-1.5.4-1 shall work as expected. Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat On 04/13/2011 07:05 PM, Trevor T Kates wrote: List: Spacewalk Version: 1.4-RC OS Version: CentOS 5.6 The attached output is written to catalina.out while attempting to upload a GPG Key or Kickstart File to Spacewalk. The files can be uploaded using the spacecmd CLI; however, the web interface fails to achieve the desired results. Please let me know if any additional information is needed and thank you for the assistance. ___ Trevor T. Kates 2011-04-13 12:44:54,773 [TP-Processor1] ERROR com.redhat.rhn.frontend.servlets.SessionFilter - Error during transaction. Rolling back javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:101) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:142) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:67) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:108) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:55) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:636) 2011-04-13 12:44:54,774 [TP-Processor1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rhn].[action] - Servlet.service() for servlet action threw exception java.lang.ClassNotFoundException: org.apache.commons.fileupload.FileUploadException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1374) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1220) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at
Re: [Spacewalk-list] triggering scripts on a client machine
What I'd like to ask is how can I make spacewalk deploy a file (bash script ) and trigger it to execute ? is that at all possible ? Yes. The easiest way is simply to schedule a remote command to run on the server. I'm on Satellite, but I assume Spacewalk is quite similar...there is a Remote Command link for a system or a system set, and in there you can put script commands to run on the remote machine. You can schedule them to run as soon as possible, which means the next time the system checks in, or no sooner than a specific time. If you'd like to copy a script to the client and then execute it, that's a bit more tricky. Essentially you'd have to upload it via a config channel, then run (via Remote Command) something like at to get it to go. Or, I suppose you could upload the script to one of the cron folders, where it'd get picked up. But I prefer the first method, of using Remote Command. Also is there a way to do a bulk upload of files to spacewalk ? I have about 60+ scripts that I need to upload so a bulk upload will be very handy. Yep, and fairly straightforward. Use the Spacewalk APIs, which you can script with Perl, Python, Java, et al. If you're familiar with Python, I have a couple of scripts that do this already for my Satellite installation. The API isn't that tough to get started with. But, if you're wanting to upload the scripts and then execute them remotely, that's a bit more involved. Brian Collins, RHCE Systems Engineer Southeastern Data Cooperative bri...@sedata.com ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] triggering scripts on a client machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 what I want to do is upload the files once ( the 60+ files ) ,but be able to schedule a remote command to run on a weekly/monthly basis . i guess the second part can be done via a cron entry . On 14 Apr 2011, at 12:49, Brian Collins wrote: What I'd like to ask is how can I make spacewalk deploy a file (bash script ) and trigger it to execute ? is that at all possible ? Yes. The easiest way is simply to schedule a remote command to run on the server. I'm on Satellite, but I assume Spacewalk is quite similar...there is a Remote Command link for a system or a system set, and in there you can put script commands to run on the remote machine. You can schedule them to run as soon as possible, which means the next time the system checks in, or no sooner than a specific time. If you'd like to copy a script to the client and then execute it, that's a bit more tricky. Essentially you'd have to upload it via a config channel, then run (via Remote Command) something like at to get it to go. Or, I suppose you could upload the script to one of the cron folders, where it'd get picked up. But I prefer the first method, of using Remote Command. Also is there a way to do a bulk upload of files to spacewalk ? I have about 60+ scripts that I need to upload so a bulk upload will be very handy. Yep, and fairly straightforward. Use the Spacewalk APIs, which you can script with Perl, Python, Java, et al. If you're familiar with Python, I have a couple of scripts that do this already for my Satellite installation. The API isn't that tough to get started with. But, if you're wanting to upload the scripts and then execute them remotely, that's a bit more involved. Brian Collins, RHCE Systems Engineer Southeastern Data Cooperative bri...@sedata.com ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.1.0 (Build 860) Charset: us-ascii wsBVAwUBTabrTGK6JZrjLX7GAQhoqwgAlSRAbFuhrgAPvRvfpnBhOlQkXY+Z1Kkp MY5AYDyWbbFZ+XQ3mh8IKmjGk4bdX6Np5ltXEa5UUixOPpNSZgfLxY6oBESUYUwP mMuqh+obl6hRVhHaUSUwSsPmqv18szi6f/ZKB2OvUJxOjqodjwQOb6OPA7OjOxky HBYHCM0x/g0UlgkRQrNU37jA1r7hKBL/xdpTBpcGFjBrp2pssK1aqa2b3DaiHHJi 28tpPoEBwyP4cKt218acEXupJ5VzyZ/cTq39A4/v0XusxgQowOJHUp5IBEVxa3ha JqzBsn/tpPOYnRPizXB+yvjFUzY2QMQjOJzXYL4qaqiSgVlPBhOFQg== =qgZV -END PGP SIGNATURE- ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] ISE While Attempting to Upload GPG Key or Kickstart File
thank you for the report. I've fixed the issue. spacewalk-java-1.5.4-1 shall work as expected. Thank you! Will this fix be available in Spacewalk 1.4 or is there a patch available that I can apply to spacewalk-java-1.4.35-1? ___ Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] triggering scripts on a client machine
what I want to do is upload the files once ( the 60+ files ) ,but be
able to
schedule a remote command to run on a weekly/monthly basis .
i guess the second part can be done via a cron entry .
[]
Correct. In fact, you can upload the files (to say, /usr/local/sbin),
and then also upload a cron table to root's (or someone else's) cron
(/var/spool/cron/root), or just put symlinks in
/etc/cron.{weekly,daily,etc}. The API lets you upload symlinks just
like it does files.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Packages associated with wrong channel
On 04/06/2011 04:54 AM, Sander Grendelman wrote: On Mon, Apr 04, 2011 at 02:18:42PM -0600, Jason M. Nielsen wrote: After a long time of poking around I noticed a pattern and it appears to be related to errata that were submitted into spacewalk. The script I use is not capable of supplying a channel name so it is submitted to all channels. I presumed that even with the errata in all channels it would still only be the errata and only apply if the rpm existed in the channel. Actually it would seem by pushing the errata to all channels it results in those rpms becoming associated with the channel with one exception. Architecture is held correctly. That is, Im not seeing x8664 rpms associated with i386 channels. I realize that if this is what caused the problem then its the b0rked script but what Im wondering is does Spacewalk automatically associate an rpm with a channel just because errata for the rpm has been submitted to that channel? It seems to me that packages should only be associated to a channel by an explicit push of some sort (in my case rhnpush) and no other reason. It could be the script itself did this as one section looks like it very well might be pushing packages and not just errata. Im completely unfamiliar with the api though. I've also run into this problem, it seems that publishing an erratum to multiple channels can cause associated packages to be pushed to some of those channels too. This can also cause centos5-packages to appear in centos4 channels :(. A workaround is to publish the erratum without associated packages and associating packages afterwards. In my opinion this is a bug, I don't know if there is already a bugzilla report for this one? I tried disassociating the errata with the channels but the rpm still shows up in the package list. Its looking like the only method to reliably clean this up will be start from scratch. Maybe I can just wipe the rhel4 channels. If it was not the script and related to the errata then Im baffled as to what caused this. It is very probable that this was caused by the script, deleting the packages should also work. You can probably search for packages with el5 in their name through the api and delete the resulting packages from your rhel4 channels. This is the script I used (get_errata.pl): http://sourceforge.net/projects/rhn2spacewalk/files/ I don't see an errata-publishing step in this script but I do see that errata are created with their relevant packages attached. What works for me when publishing an erratum through the api is: 1) Create erratum _without packages_. 2) Publish erratum to the relevant channels. 3) Add packages to the erratum. This way no packages are pushed to the wrong channel. An extra benefit is that publishing the erratum without packages is a lot quicker. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list So I modified the script and submitted the thought on the sourceforge open discussion board but in case anyone is interested take a look at: https://sourceforge.net/projects/rhn2spacewalk/forums/forum/1266739/topic/4482538 It only submits errata to the channels that have the associated package. Not pretty but its worked thus far. begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Removing errata disassociates packages with channels
Spacewalk 1.2: I discovered that removing an errata causes all of the associated packages with said errata to end up in no channels. I could be wrong but this seems like a bug. I have not tested all scenarios but it seems you could have at least two legit reasons to do this and not affect the packages. 1)Incorrectly setup errata. 2)Errata associated with one arch and not the other yet it has all packages listed, no way to separate. Just a thought. begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] ISE While Attempting to Upload GPG Key or Kickstart File
On 04/14/2011 02:47 PM, Trevor T Kates wrote: thank you for the report. I've fixed the issue. spacewalk-java-1.5.4-1 shall work as expected. Thank you! Will this fix be available in Spacewalk 1.4 or is there a patch available that I can apply to spacewalk-java-1.4.35-1? The fix will definitely land in Spacewalk 1.4. But I am not sure, when the package lands in the repo. For the time being just pick spacewalk-java-1.4.36-1 directly from koji depending on your OS: https://koji.spacewalkproject.org/koji/packageinfo?packageID=1438 Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat ___ Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Removing errata disassociates packages with channels
On 04/14/2011 05:17 PM, Jason M. Nielsen wrote: Spacewalk 1.2: I discovered that removing an errata causes all of the associated packages with said errata to end up in no channels. I could be wrong but this seems like a bug. I have not tested all scenarios but it seems you could have at least two legit reasons to do this and not affect the packages. 1)Incorrectly setup errata. 2)Errata associated with one arch and not the other yet it has all packages listed, no way to separate. Just a thought. I believe this is correct scenario. And you can very easily delete all packages, which is in no channel - AFAIK just 3 clicks. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Removing errata disassociates packages with channels
On 04/14/2011 09:28 AM, Miroslav Suchý wrote: On 04/14/2011 05:17 PM, Jason M. Nielsen wrote: Spacewalk 1.2: I discovered that removing an errata causes all of the associated packages with said errata to end up in no channels. I could be wrong but this seems like a bug. I have not tested all scenarios but it seems you could have at least two legit reasons to do this and not affect the packages. 1)Incorrectly setup errata. 2)Errata associated with one arch and not the other yet it has all packages listed, no way to separate. Just a thought. I believe this is correct scenario. And you can very easily delete all packages, which is in no channel - AFAIK just 3 clicks. What if you dont want the packages removed, only the errata? begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Removing errata disassociates packages with channels
On Thu, 14 Apr 2011, Jason M. Nielsen wrote: On 04/14/2011 09:28 AM, Miroslav Suchý wrote: On 04/14/2011 05:17 PM, Jason M. Nielsen wrote: Spacewalk 1.2: I discovered that removing an errata causes all of the associated packages with said errata to end up in no channels. I could be wrong but this seems like a bug. I have not tested all scenarios but it seems you could have at least two legit reasons to do this and not affect the packages. 1)Incorrectly setup errata. 2)Errata associated with one arch and not the other yet it has all packages listed, no way to separate. Just a thought. I believe this is correct scenario. And you can very easily delete all packages, which is in no channel - AFAIK just 3 clicks. What if you dont want the packages removed, only the errata? hi jason, i believe you first have to remove the package from the errata. this can be done from the web interface through 'manage errata', in the 'packages' section. once you have removed the package from the errata, it should be possible to delete the errata, without also deleting the packages. it looks like there are relevant api calls to do the same, though i personally haven't used these before. thanks, richard___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Removing errata disassociates packages with channels
On 04/14/2011 10:01 AM, r.ri...@leeds.ac.uk wrote: On Thu, 14 Apr 2011, Jason M. Nielsen wrote: On 04/14/2011 09:28 AM, Miroslav Suchý wrote: On 04/14/2011 05:17 PM, Jason M. Nielsen wrote: Spacewalk 1.2: I discovered that removing an errata causes all of the associated packages with said errata to end up in no channels. I could be wrong but this seems like a bug. I have not tested all scenarios but it seems you could have at least two legit reasons to do this and not affect the packages. 1)Incorrectly setup errata. 2)Errata associated with one arch and not the other yet it has all packages listed, no way to separate. Just a thought. I believe this is correct scenario. And you can very easily delete all packages, which is in no channel - AFAIK just 3 clicks. What if you dont want the packages removed, only the errata? hi jason, i believe you first have to remove the package from the errata. this can be done from the web interface through 'manage errata', in the 'packages' section. once you have removed the package from the errata, it should be possible to delete the errata, without also deleting the packages. it looks like there are relevant api calls to do the same, though i personally haven't used these before. thanks, richard Perhaps a feature request. A toggle box that says dont move packages. ie: errata.removePackages then errata.delete. Thanks, Jason. begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Undefined Global in osad.py in osad 5.10.9 and 5.10.10
Miroslav Suchý/Jan Pazdziora: Error caught: Traceback (most recent call last): File /usr/share/rhn/osad/jabber_lib.py, line 112, in main config = self.read_config() File /usr/share/rhn/osad/osad.py, line 256, in read_config server_url = config.getServerlURL()[0] NameError: global name 'config' is not defined Error was presented by osad 5.10.9 and 5.10.10 when attempting to start the service. Kind regards, ___ Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Database Schema Update Issue - 1.2 to 1.3 Upgrade
I'm having an issue with the upgrade from v1.2 to v1.3 ... when I run the spacewalk-schema-upgrade script... it just simply returns: No existing schema version info found in rhnVersionInfo. I can make a simple connection via sqlplus.. so I know the database is running and available. Looking at the schema upgrade script... I find the query that it runs to check the schema version: select rhnPackageName.name || '-' || (PE.evr).version || '-' || (PE.evr).release from rhnVersionInfo, rhnPackageName, rhnPackageEVR PE where rhnVersionInfo.label = 'schema' and rhnVersionInfo.name_id = rhnPackageName.id and rhnVersionInfo.evr_id = PE.id; And when I run that manually via sqlplus .. I get no rows returned. Has anyone seen this issue? Yes. It means your previous schema upgrade (to Spacewalk 1.2) failed. Check log files in /var/log/spacewalk/schema-upgrade for reasons why. Right... so, this is something that came up in an earlier thread I think. During my 1.2 upgrade I had this issue with the schema: SQL set echo on SQL spool /var/log/spacewalk/schema-upgrade/20101129-165813-to-spacewalk-schema- 1.2. log append SQL whenever sqlerror exit sql.sqlcode SQL select 'spacewalk-schema-1.1-to-spacewalk-schema-1.2/210-rhnPackage- indexes.sql' from dual; 'SPACEWALK-SCHEMA-1.1-TO-SPACEWALK-SCHEMA-1.2/210-RHNPACKAGE-INDEXES.S Q -- - spacewalk-schema-1.1-to-spacewalk-schema-1.2/210-rhnPackage-indexes.sq l SQL SQL drop index rhn_package_id_nid_paid_idx; drop index rhn_package_id_nid_paid_idx * ERROR at line 1: ORA-02429: cannot drop index used for enforcement of unique/primary key However, there was a post that talked about this.. and how to fix it. Did the fix fail to add something in the database to mark it as successfully upgraded? I'm not quite sure what steps you did to fix the failed schema upgrade, nonetheless ordinarily, spacewalk-schema-upgrade would insert one line into rhnVersionInfo table at the very end of schema upgrade to indicate version of current schema. Find the 1.1 - 1.2 .sql script in /var/log/spacewalk/schema-upgrade and at the very bottom of the file, find a line: exec dbms_utility.compile_schema(user); You need to manually apply this line and everything after it using sqlplus. Very good. That was exactly what I needed. Thanks! Andy ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
