Re: [Spacewalk-devel] Cobbler 2.2 support in 1.6

2011-12-11 Thread Parsons, Aron
I committed some patches for Cobbler 2.2 support tonight.  It'd be great if a 
few others could test to ensure I didn't break anything before 1.6 is released.

I tested the following scenarios:
- fresh Cobbler 2.0 install
- fresh Cobbler 2.2 install
- 2.0 to 2.2 upgrade

And these operations:
- create new kickstart
- update existing kickstart
- create cobbler record for a system

/aron

From: spacewalk-devel-boun...@redhat.com [spacewalk-devel-boun...@redhat.com] 
on behalf of spacewalk-devel-requ...@redhat.com 
[spacewalk-devel-requ...@redhat.com]
Sent: Thursday, December 01, 2011 12:00 PM
To: spacewalk-devel@redhat.com
Subject: Spacewalk-devel Digest, Vol 43, Issue 1

Send Spacewalk-devel mailing list submissions to
spacewalk-devel@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-devel
or, via email, send a message with subject or body 'help' to
spacewalk-devel-requ...@redhat.com

You can reach the person managing the list at
spacewalk-devel-ow...@redhat.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Spacewalk-devel digest..."


Today's Topics:

   1. Re: client/rhel (Miroslav Suchy)
   2. Cobbler 2.2 support in 1.6 (Parsons, Aron)
   3. Re: Cobbler 2.2 support in 1.6 (Miroslav Suchy)
   4. Re: client/rhel (Jan Pazdziora)
   5. [PATCH] fix display of static snippets (Uwe Gansert)
   6. Re: [PATCH] fix display of static snippets (Jan Pazdziora)
   7. Re: [PATCH] fix display of static snippets (Uwe Gansert)
   8. Re: [PATCH] fix display of static snippets (Jan Pazdziora)
   9. Re: [PATCH] fix display of static snippets (Uwe Gansert)


--

Message: 1
Date: Wed, 30 Nov 2011 18:42:54 +0100
From: Miroslav Suchy 
To: spacewalk-devel@redhat.com
Subject: Re: [Spacewalk-devel] client/rhel
Message-ID: <4ed66b1e.7080...@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dne 30.11.2011 17:40, Jan Pazdziora napsal(a):
> I don't think you want to just blindly set what getfqdn returns. In
> most cases, IPv4 addresses will have better DNS records than IPv6 but

That is just assumption. In most cases correct. But all this code is
just wild heuristics trying to do less evil.

I can change the order of
   for family in (AF_INET, AF_INET6):
in findHostByRoute() to:
   for family in (AF_INET6, AF_INET):
I have to admit this will get better data more often.

> you will end up with stuff like
>
>   # python -c 'from socket import *; print
>   getfqdn("2620:52:0:2223:20c:29ff:fe0e:d05b");' 
> 2620:52:0:2223:20c:29ff:fe0e:d05b
>
> in the hostname. You should really check (and test) various scenarios,
> not overwrite the hostname if it already is set from the IPv4 pass,
> and not set it if you get IP address back.

How should I decide which hostname is correct?

And what should I do with machine with IPv4 address 123.45.56.67 which
resolves to machine1.broken.dns and IPv6 address
2620:52:0:2223:20c:29ff:fe0e:d05b which resolves machine2.broken.dns?

If you are unable to resolve the hostname using gethostbyaddr()
(getfqdn() is essentially wrapper around this one function), then you do
not deserve sane data. If user has broken networking, he should fix it
in first place.

Hmm what I can do is:
hostname_tmp = socket.getfqdn(intf_tmp)
if hostname_tmp != intf_tmp:
hostname = hostname_tmp

But you can admit, that user can be so ugly, that machine with hostname
123.45.56.67 will have IPv4 address 123.45.56.67.

I do not think we can catch all possibilities here.

Mirek



Mirek






--

Message: 2
Date: Wed, 30 Nov 2011 18:19:06 +
From: "Parsons, Aron" 
To: "'spacewalk-devel@redhat.com'" 
Subject: [Spacewalk-devel] Cobbler 2.2 support in 1.6
Message-ID:
<38BF0DD94618A6449F9DC97ECCB360A90DB9B923@suhn-mbx2.SIX3.local>
Content-Type: text/plain; charset="us-ascii"

How do we want to handle Cobbler 2.2 support in the upcoming release?  2.2 has 
some nice features and I think it'd be good to support it.  Do we want to drop 
2.0 support or try to work some logic in to detect the Cobbler version?  I'm 
not sure if we'd want to bring that into places like KickstartFormatter.java.

The items that would need changed in Spacewalk based on a quick look:
- kickstart_{start,done} macros to snippets in 
com.redhat.rhn.manager.kickstart.KickstartFormatter
- 'subnet' field changed to 'netmask' in org.cobbler.Network

Am I missing any other changes?  Is anyone else already working on this?

/aron



--

Message: 3
Date: Thu, 01 Dec 2011 10:05:57 +0100
From: Miroslav Suchy 
To: spacewalk-devel@redhat.com
Subject: Re: [Spacewalk-devel] Cobbler 2.2 support in 1.6
Message-ID: <4ed74375.30...@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dne 30.11.2011 19:19, Parsons, Aron napsal

Re: [Spacewalk-devel] [PATCH 4/4] spacecmd bugfix : Fix of/if typo in activationkey_export help

2011-12-11 Thread Parsons, Aron
All committed.  Thanks Steve.

/aron

From: Steve Hardy [sha...@redhat.com]
Sent: Friday, December 09, 2011 4:49 AM
To: spacewalk-devel@redhat.com
Cc: Parsons, Aron
Subject: [PATCH 4/4] spacecmd bugfix : Fix of/if typo in activationkey_export 
help

---
 spacecmd/src/lib/activationkey.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/spacecmd/src/lib/activationkey.py 
b/spacecmd/src/lib/activationkey.py
index aad3208..71c24ae 100644
--- a/spacecmd/src/lib/activationkey.py
+++ b/spacecmd/src/lib/activationkey.py
@@ -926,7 +926,7 @@ def help_activationkey_export(self):
 options:
 -f outfile.json : specify an output filename, defaults to .json
   if exporting a single key, akeys.json for multiple keys,
-  or akey_all.json of no KEY specified (export ALL)
+  or akey_all.json if no KEY specified (export ALL)

 Note : KEY list is optional, default is to export ALL keys '''

--
1.7.1


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