Re: [Spacewalk-list] rhnreg_ks on F15
On Wed, Apr 13, 2011 at 22:07, Miroslav Suchy 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: 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: 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: 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: 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: 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: 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: 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: 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: device number: 48515 device file: /dev/bus/usb/002/004 device file symlinks: UDEV_LOG = 3 DEVPATH = /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1 SUBSYSTEM = usb MAJOR = 189 MINOR = 131 DEVNAME = /dev/bus/usb/002/004 DEVTYPE = usb_device DRIVER = usb DEVICE = /proc/bus/usb/002/004 PRODUCT = 4d9/1603/310 TYPE = 0/0/0 BUSNUM = 002 DEVNUM = 004 subsystem usb devtype usb_interface name 2-1.1.1:1.0 number 0 sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0 driver: usbhid action: None seqnum: 0 device type:
Re: [Spacewalk-list] rhnreg_ks on F15
On Wed, Apr 13, 2011 at 21:39, Miroslav Suchy wrote: > Dne 13.4.2011 14:52, Sandro "red" Mathys napsal(a): >>> >>> It happens during gathering HW info. So if you run it with --nohardware, >>> > you can workaround it. >> >> --nohardware doesn't resolve the issue, i.e. no change at all. >> > > > Aha, I got it. You do not have HAL installed or running. > The code try to first retrive data from HAL, if it is not present it will > try gudev, where is the bug. > > To workaround the bug, make sure HAL is running. Unfortunately this is Fedora 15 (nightly) and HAL is being removed from Fedora per this feature: http://fedoraproject.org/wiki/Features/HalRemoval So we do want the gudev stuff - but we need it in working order ;) Thanks :D ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] rhnreg_ks on F15
2011/4/13 Miroslav Suchý :
> On 04/13/2011 02:52 PM, Sandro "red" Mathys wrote:
>> 2011/4/13 Miroslav Suchý :
>>> It is some USB device. Can you run this python script in both %post
>>> section of kickstart and after normal reboot? Check the diferences.
>>> You should look for records with
>>> XXX: None
>>
>> Lots of XXX: None found, actually it's always None!
>
> That is strange... aha, there is typo. It should be PRODUCT and not product.
> Commited as ebd9948a92945026db88932eefd23c4c0c7738ea
Next issue: ~4 lines later, "usb" is not defined:
: local variable 'usb' referenced
before assignment
If I add "usb = USB()" (as found in the first part of that
if-elif-else construct) before that line, I get the next traceback:
[Wed Apr 13 15:18:51 2011] up2date
Traceback (most recent call last):
File "/usr/sbin/rhnreg_ks", line 213, in
cli.run()
File "/usr/share/rhn/up2date_client/rhncli.py", line 74, in run
sys.exit(self.main() or 0)
File "/usr/sbin/rhnreg_ks", line 101, in main
hardwareList = hardware.Hardware()
File "/usr/share/rhn/up2date_client/hardware.py", line 674, in Hardware
allhw = get_devices()
File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 45, in
get_devices
'desc': _get_device_desc(device),
File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 311, in
_get_device_desc
result = "%s|%s" % (usb.get_vendor(vendor_id),
usb.get_device(vendor_id, device.get_property('ID_MODEL_ID')))
File "/usr/lib/python2.7/site-packages/hwdata.py", line 82, in get_device
device = device.lower()
: 'NoneType' object has no attribute 'lower'
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] rhnreg_ks on F15
2011/4/13 Miroslav Suchý :
> On 04/13/2011 08:24 AM, Sandro "red" Mathys wrote:
>> Hi,
>>
>> We tried to deploy a F15 system (with the latest from updates-testing)
>> from spacewalk 1.3 which works just fine (yay!) except for rhnreg_ks
>> (rhn-setup 1.4.15-1.fc14) which fails with the following traceback:
>>
>> [Tue Apr 12 16:15:15 2011] up2date
>> Traceback (most recent call last):
>> File "/usr/sbin/rhnreg_ks", line 213, in
>> cli.run()
>> File "/usr/share/rhn/up2date_client/rhncli.py", line 74, in run
>> sys.exit(self.main() or 0)
>> File "/usr/sbin/rhnreg_ks", line 101, in main
>> hardwareList = hardware.Hardware()
>> File "/usr/share/rhn/up2date_client/hardware.py", line 674, in Hardware
>> allhw = get_devices()
>> File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 45, in
>> get_devices
>> 'desc': _get_device_desc(device),
>> File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 306, in
>> _get_device_desc
>> (vendor_id, model_id) = device.get_property('product').split('/')[:2]
>> : 'NoneType' object has no attribute
>> 'split'
>>
>> It seems that device.get_propery('product') returns None but does
>> somebody have an idea why it does so? On what information does this
>> rely? i.e. is there a service not running that should be or a package
>> missing?
>>
>> Is the extracted information actually important? If not, the thrown
>> exception should rather be caught.
>
>
> It happens during gathering HW info. So if you run it with --nohardware,
> you can workaround it.
--nohardware doesn't resolve the issue, i.e. no change at all.
> It is some USB device. Can you run this python script in both %post
> section of kickstart and after normal reboot? Check the diferences.
> You should look for records with
> XXX: None
Lots of XXX: None found, actually it's always None!
>
> import gudev
> import glib
>
> print "GUDEV VERSION: %s" % gudev.__version__
>
> def print_device(device):
> print "subsystem", device.get_subsystem()
> print "devtype", device.get_devtype()
> print "name", device.get_name()
> print "number", device.get_number()
> print "sysfs_path:", device.get_sysfs_path()
> print "XXX: ", device.get_property('product')
>
> devices = client.query_by_subsystem("usb")
The variable client is not defined at this point, so I added:
client = gudev.Client([""])
> for device in devices:
> print_device(device)
>
>
> But yeah, having test before that split is probably good idea. I will
> put it in master, but this is not worth of backporting to 1.4.
I would disagree here, IMHO.
Here's the full output of your debug script:
GUDEV VERSION: 147.1
subsystem usb
devtype usb_device
name usb1
number 1
sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1
XXX: None
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
XXX: None
subsystem usb
devtype usb_device
name 1-1
number 1
sysfs_path: /sys/devices/pci:00/:00:1a.0/usb1/1-1
XXX: None
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
XXX: None
subsystem usb
devtype usb_device
name usb2
number 2
sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2
XXX: None
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
XXX: None
subsystem usb
devtype usb_device
name 2-1
number 1
sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1
XXX: None
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
XXX: None
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
XXX: None
subsystem usb
devtype usb_interface
name 2-1.1.1:1.0
number 0
sysfs_path:
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0
XXX: None
subsystem usb
devtype usb_interface
name 2-1.1.1:1.1
number 1
sysfs_path:
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.1
XXX: None
subsystem usb
devtype usb_device
name 2-1.1.4
number 4
sysfs_path: /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.4
XXX: None
subsystem usb
devtype usb_interface
name 2-1.1.4:1.0
number 0
sysfs_path:
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.4/2-1.1.4:1.0
XXX: None
subsystem usb
devtype usb_interface
name 2-1.1.4:1.1
num
Re: [Spacewalk-list] rhnreg_ks on F15
On Wed, Apr 13, 2011 at 08:24, Sandro "red" Mathys
wrote:
> Hi,
>
> We tried to deploy a F15 system (with the latest from updates-testing)
> from spacewalk 1.3 which works just fine (yay!) except for rhnreg_ks
> (rhn-setup 1.4.15-1.fc14) which fails with the following traceback:
>
> [Tue Apr 12 16:15:15 2011] up2date
> Traceback (most recent call last):
> File "/usr/sbin/rhnreg_ks", line 213, in
> cli.run()
> File "/usr/share/rhn/up2date_client/rhncli.py", line 74, in run
> sys.exit(self.main() or 0)
> File "/usr/sbin/rhnreg_ks", line 101, in main
> hardwareList = hardware.Hardware()
> File "/usr/share/rhn/up2date_client/hardware.py", line 674, in Hardware
> allhw = get_devices()
> File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 45, in
> get_devices
> 'desc': _get_device_desc(device),
> File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 306, in
> _get_device_desc
> (vendor_id, model_id) = device.get_property('product').split('/')[:2]
> : 'NoneType' object has no attribute 'split'
>
> It seems that device.get_propery('product') returns None but does
> somebody have an idea why it does so? On what information does this
> rely? i.e. is there a service not running that should be or a package
> missing?
>
> Is the extracted information actually important? If not, the thrown
> exception should rather be caught.
>
> Thanks,
> red
PS. the exact same rhnreg_ks command seems to work fine after the
reboot so it must be something that is different in %post and in the
final/rebooted system.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] rhnreg_ks on F15
Hi,
We tried to deploy a F15 system (with the latest from updates-testing)
from spacewalk 1.3 which works just fine (yay!) except for rhnreg_ks
(rhn-setup 1.4.15-1.fc14) which fails with the following traceback:
[Tue Apr 12 16:15:15 2011] up2date
Traceback (most recent call last):
File "/usr/sbin/rhnreg_ks", line 213, in
cli.run()
File "/usr/share/rhn/up2date_client/rhncli.py", line 74, in run
sys.exit(self.main() or 0)
File "/usr/sbin/rhnreg_ks", line 101, in main
hardwareList = hardware.Hardware()
File "/usr/share/rhn/up2date_client/hardware.py", line 674, in Hardware
allhw = get_devices()
File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 45, in
get_devices
'desc': _get_device_desc(device),
File "/usr/share/rhn/up2date_client/hardware_gudev.py", line 306, in
_get_device_desc
(vendor_id, model_id) = device.get_property('product').split('/')[:2]
: 'NoneType' object has no attribute 'split'
It seems that device.get_propery('product') returns None but does
somebody have an idea why it does so? On what information does this
rely? i.e. is there a service not running that should be or a package
missing?
Is the extracted information actually important? If not, the thrown
exception should rather be caught.
Thanks,
red
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] repo sync crashing
On Thu, Feb 10, 2011 at 21:01, Michael Mraka wrote: > Bingo :). > > It was a leaked file descriptor. It's been fixed in nightly. > Thanks both of you for the report and the hint. Could we get this backported to 1.3, please? I see this error every ~600 packages when syncing Fedora. Seeing that e.g. F14 x86_64 release+updates has ~30k packages this will take way too many tries - not to mention syncing other arches and versions of Fedora, too :) Also, it's a regression from 1.2 ;) Thanks, red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Fix for jabberd / osad issues now in repos
On Fri, Nov 26, 2010 at 17:06, Jan Pazdziora wrote:
> On Fri, Nov 26, 2010 at 04:54:49PM +0100, Sandro "red" Mathys wrote:
>> On 11/26/2010 10:11 AM, Jan Pazdziora wrote:
>> >
>> >both nightly and Spacewalk 1.2 repos now contain new
>> >spacewalk-setup-jabberd packages which address the issues with
>> >jabberd 2.2.11.
>>
>> Not sure what issue you meant, but my OSA issue is not fixed yet. I
>
> Jabberd error
>
> request to start session in non-serviced domain
>
> in /var/log/messages every five minutes and osad not picking up
> actions.
You just made me have a close look at the syslog and there I found
this, not sure if it does any harm though:
Nov 26 17:20:25 id-sws-prd jabberd/sm[2624]: failed loading module
'disco-publish' to chain 'user-delete'
(/usr/lib64/jabberd/mod_disco-publish.so: cannot open shared object
file: No such file or directory)
>
>> still see no errors on either side but OSA ping doesn't work enyway
>
> Please be more specific about "doesn't work".
Okay.
What works without errors:
- jabberd
- osa-dispatcher
- osad (on client)
What doesn't work:
- OSA ping and remote commands that use OSA (i.e. rhn_check works)
But I recently found out that osa-dispatcher behaves differently in two cases:
- if jabberd's db was cleared, it starts with no error
- if jabberd's db was not cleared, it *sometimes* (i.e. mostly not)
throws an error:
Starting osa-dispatcher: RHN 948 2010/11/26 17:19:05 +02:00: ('Server
did not return a stanza',)
RHN 948 2010/11/26 17:19:05 +02:00: ('Traceback (most recent call
last):\n File "/usr/share/rhn/osad/jabber_lib.py", line 254, in
setup_connection\nc = self._get_jabber_client(js)\n File
"/usr/share/rhn/osad/jabber_lib.py", line 311, in _get_jabber_client\n
c.connect()\n File "/usr/share/rhn/osad/jabber_lib.py", line 584,
in connect\nraise SSLDisabledError\nSSLDisabledError\n',)
I really have no idea why this error shwos up sometimes but not always
or what's the cause for this. Also, osad never says anything about a
missing features stanza.
-- red
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Fw: WEB TRACEBACK on remote command [1.2]
On Fri, Nov 26, 2010 at 14:24, Jan Pazdziora wrote: > On Tue, Nov 23, 2010 at 03:01:06PM +0100, Rene Lehmann wrote: >> >> i got the following WEB TRACEBACK by using a remote command on the ssm. > > Could you please apply patch from > > > http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=3dc3e6d8986ec442d2a6ab651100840c34c9690e > > to /usr/lib/perl5/vendor_perl/5.8.8/RHN/DB.pm? That should get rid > of the Internal Server Error. I can confirm that patch solves this issue. Would be nice to see it being backported to 1.2 :) > -- > Jan Pazdziora > Principal Software Engineer, Satellite Engineering, Red Hat > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Fix for jabberd / osad issues now in repos
On 11/26/2010 10:11 AM, Jan Pazdziora wrote: Folks, both nightly and Spacewalk 1.2 repos now contain new spacewalk-setup-jabberd packages which address the issues with jabberd 2.2.11. Not sure what issue you meant, but my OSA issue is not fixed yet. I still see no errors on either side but OSA ping doesn't work enyway :/ The steps to recover are: 1) # yum upgrade spacewalk-setup-jabberd and make sure you get at least version 1.3.1-1. 2) # service jabberd stop 3) # spacewalk-setup-jabberd --verbose 4) # rm -rf /var/lib/jabberd/db/* 5) # service jabberd start Yours, ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problems after 1.1 -> 1.2 upgrade
On Fri, Nov 26, 2010 at 10:29, Lukas Zapletal wrote: > Hello > > On 11/25/2010 04:28 PM, Sandro "red" Mathys wrote: >> >> Thanks for the backport. I can confirm, that the ISE has been fixed. > > Cool. > >> But now there's no health-icons in the systems overview (yes, I have >> added the systems to a probe suite and yes, they show health icons in >> the monitoring tab under status). > > This is known bug. This error does occur on Webkit browsers (and maybe > others). The workaroud is to use Firefox. Firefox is not affected with this > one. I do use Firefox already - ff4b7, though :) > > https://bugzilla.redhat.com/show_bug.cgi?id=656311 > > It has been already fixed in master. > > commit c36b7847e118239af21ef284160693308e1db91b > Author: Lukas Zapletal > Date: Tue Nov 23 14:08:44 2010 +0100 > > LZ > > -- > Later, > Lukas "lzap" Zapletal > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problems after 1.1 -> 1.2 upgrade
On 11/25/2010 03:04 PM, Jan Pazdziora wrote: On Thu, Nov 25, 2010 at 10:13:18AM +0100, Lukas Zapletal wrote: I tried the spacewalk-java-1.3.13-1.el5.noarch.rpm package from nightly and it did not resolve the provisioning issue. Hello, these three commits were solving only the monitoring Internal Server Error issue. I have just backported them into the 1.2. We will release the update likely tomorrow. Packages for spacewalk-web-1.2.28-1 and spacewalk-java-1.2.114-1 are now in Spacewalk 1.2 repos. Thanks for the backport. I can confirm, that the ISE has been fixed. But now there's no health-icons in the systems overview (yes, I have added the systems to a probe suite and yes, they show health icons in the monitoring tab under status). -- red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problems after 1.1 -> 1.2 upgrade
On Mon, Nov 22, 2010 at 17:21, Lukas Zapletal wrote: >> Hi Lukas, >> Then probably is this, becouse I have about 80 monitored systems. >> >> Please give me a post when yu push the fix. >> Thank you. > > Hello, > > this series of thee commits fix the problem: > > f8fc790513588228feb21b97b590e63fa01bf64b > baa480636bd9c63c5568fc464c1d23b6b55b9faa > 5e52731a3ea813ea17a3dba463a49a766772f262 > > Its in the package [spacewalk-java] release [1.3.12-1] and today it will hit > the 1.3-nightly. A backport and release to 1.2 would really be appreciated. -- red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] deleting packages
On Tue, Nov 23, 2010 at 12:07, Colin Coe wrote: > On Tue, Nov 23, 2010 at 4:07 PM, Sandro "red" Mathys > wrote: >> On 11/22/2010 11:41 PM, Colin Coe wrote: >>> >>> On Tue, Nov 23, 2010 at 2:57 AM, Marcus Moeller >>> wrote: >>>> >>>> Dear Jan. >>>> >>>>>>> On you Spacewalk, go to >>>>>>> >>>>>>> >>>>>>> https://FQDN/rhn/apidoc/handlers/PackagesHandler.jsp#removePackage >>>>>>> >>>>>>> Hope this helps, >>>>>> >>>>>> You still have to hack orphan package IDs out of the database directly >>>>>> which is quite annoying. >>>>> >>>>> Obviously, patches welcome. >>>> >>>> Please note that not all of us are coders. What I can do is to report >>>> bugs and to help improving the product that way (as I always did in >>>> the past). >>>> >>>> If there will be any form of interest in setting up a QA process I am >>>> also willed to help. >>>> >>>> -- >>>> Greets >>>> Marcus >>>> >>> >>> Hi all >>> >>> I should be able to come up with a 'packages.findOrphans' API call. >>> It would only be able to be run by a Satellite admin. >>> >>> Jan, would that be acceptable from a security/maintenance perspective? >>> >>> Marcus, would that help solve the problem in the original post? >>> >>> CC >>> >> >> Hi Colin, >> >> How would that API call be different from >> channel.software.listPackagesWithoutChannel? >> >> Actually, I think it would help already, if listPackagesWithoutChannel would >> have some (new) limiting parameters to only select a smaller chunk of >> packages and thereby work around the 502 problem. >> >> -- red >> > > heh, should have done more homework, shouldn't I :) > > I'm wondering if channel.software.listPackageIDsWithoutChannel would > get around the problem by only returning package IDs? As the amount > of data per package would be greatly reduced this may help. > > I think the limit idea is a good one. I guess you mean something like > channel.software.listPackagesWithoutChannel(sessionKey, 500) to return > the first 500 packages not in a channel. > > It'd be interesting if we could save state so that the first time you > call channel.software.listPackagesWithoutChannel(sessionKey, 500) in a > session you get the first 500 packages and subsequent times you get > the next 500 and so on until the session expires, auth.logoff is > called, or the last of the packages without a channel are retrieved. I'd suggest to make it more flexible, i.e. either listPackagesWithoutChannel(sKey, startOfRange, endOfRange) or lPWC(sK, startOfRange, rangeSize/numberOfPackages) but both should work for the case discussed in this thread. -- red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] deleting packages
On 11/22/2010 11:41 PM, Colin Coe wrote: On Tue, Nov 23, 2010 at 2:57 AM, Marcus Moeller wrote: Dear Jan. On you Spacewalk, go to https://FQDN/rhn/apidoc/handlers/PackagesHandler.jsp#removePackage Hope this helps, You still have to hack orphan package IDs out of the database directly which is quite annoying. Obviously, patches welcome. Please note that not all of us are coders. What I can do is to report bugs and to help improving the product that way (as I always did in the past). If there will be any form of interest in setting up a QA process I am also willed to help. -- Greets Marcus Hi all I should be able to come up with a 'packages.findOrphans' API call. It would only be able to be run by a Satellite admin. Jan, would that be acceptable from a security/maintenance perspective? Marcus, would that help solve the problem in the original post? CC Hi Colin, How would that API call be different from channel.software.listPackagesWithoutChannel? Actually, I think it would help already, if listPackagesWithoutChannel would have some (new) limiting parameters to only select a smaller chunk of packages and thereby work around the 502 problem. -- red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Looking for slides to present spacewalk at FOSDEM
Hi folks, I know some of you have held some presentations about spacewalk in the past and as I've seen one or two of them I also know they're really well done. As Marcus Moeller and I will be giving a talk on that matter during FOSDEM (http://fosdem.org/) I was wondering whether you guys would kindly share your slides :) Please don't reply with slides of which you're not the original author as it's very important that the original author allows the usage of his slides :) Don't forget to mention on what terms the slides can be used/modified - i.e. what's their license (unless the slides state that themselves). Thanks, red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] PXE SystemID is not deleted after kickstart
On Thu, Oct 29, 2009 at 11:25 AM, Jan Pazdziora wrote: > Yep, that's OK. Could you please ask support to link that ticket to > this bugzilla? I'm affraid that I don't see the ticket now. Done. Thanks for adding it to the sat531-triage bug tracker :) ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] PXE SystemID is not deleted after kickstart
On Thu, Oct 29, 2009 at 9:54 AM, Jan Pazdziora wrote: > Could you please file a bug in bugzilla.redhat.com, putting in the > full kickstart file / pxelinx.cfg files to the bug report? > > Thank you, > > -- > Jan Pazdziora > Senior Software Engineer, Satellite Engineering, Red Hat Hi, I opened this against Satellite (because we also have a RH Support ticket (#1965166) running for this issue as we see the issue in both, Satellite and Spacewalk): https://bugzilla.redhat.com/show_bug.cgi?id=531719 Hope that's okay or I'll go and open naother bug against Spacewalk ;) Thanks, red ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
