Re: [Spacewalk-devel] [Proposal] Schema change of rhnServerInterface due IPv6
> I recently changed rhnServerNetwork due IPv6 and it was quite straight.
>
> Now I focused on rhnServerInterface and I want to give you chance to
> argue with me, before I do the change. :)
>
> Today the table looks like:
> http://spacewalk.redhat.com/documentation/schema-doc/table-RHNSERVERNETINTE
> RFACE.html
>
> It has columns:
> * SERVER_ID NUMBER(38)
> * NAMEVARCHAR2(32)
> IP_ADDR VARCHAR2(64)
> NETMASK VARCHAR2(64)
> BROADCAST VARCHAR2(64)
> HW_ADDR VARCHAR2(18)
> MODULEVARCHAR2(128)
> CREATED DATE
> MODIFIED DATE
>
> "*" marks primary key
>
> Previusly clients send over XMLRPC this data:
>
> intDict[interface] = {'hwaddr':hwaddr,
> 'ipaddr':ipaddr,
> 'netmask':netmask,
> 'broadcast':broadcast,
> 'module': module
> }
>
> for some time (since 2010-11-20) it send:
>
> intDict[interface] = {'hwaddr':hwaddr,
> 'ipaddr':ipaddr,
> 'netmask':netmask,
> 'broadcast':broadcast,
> 'module': module,
> 'ipv6': ip6_list}
>
> where ip6_list is:
>
> ip6_list.append({
> 'scope': ip6.scope,
> 'addr':ip6.address,
> 'netmask': ip6.netmask
> })
>
> The ipv6 key/value pair is ignored by server for now.
> The IPv6 stuff will not fit into current table so I come with following
> solution:
>
> Simplify table rhnServerInterface to columns:
> * SERVER_ID NUMBER(38)
> * NAMEVARCHAR2(32)
> HW_ADDR VARCHAR2(18)
> MODULEVARCHAR2(128)
> CREATED DATE
> MODIFIED DATE
>
> Create new table rhnServerInterfaceIPv4 with columns:
> * SERVER_ID NUMBER(38)
> * NAMEVARCHAR2(32)
> IP_ADDR VARCHAR2(64)
> NETMASK VARCHAR2(64)
> BROADCAST VARCHAR2(64)
> CREATED DATE
> MODIFIED DATE
> Migration of existing data from rhnServerInterface to this new table is
> easy and should not be problem.
>
> Create new table rhnServerInterfaceIPv6 with columns:
> * SERVER_ID NUMBER(38)
> * NAMEVARCHAR2(32)
> SCOPE VARCHAR2(19)
> ADDR VARCHAR2(45)
> NETMASK VARCHAR2(49)
> CREATED DATE
> MODIFIED DATE
>
> SCOPE can be (according rfc2373):
> scop is a 4-bit multicast scope value used to limit the scope of
> the multicast group. The values are:
>
> 0 reserved
> 1 node-local scope
> 2 link-local scope
> 3 (unassigned)
> 4 (unassigned)
> 5 site-local scope
> 6 (unassigned)
> 7 (unassigned)
> 8 organization-local scope
> 9 (unassigned)
> A (unassigned)
> B (unassigned)
> C (unassigned)
>
> longest is organization-local with 19 chars, but I seen more different
> strings already ("local", "universe" etc.).
> So I tend to think that more general VARCHAR(128) would be better here.
>
> ADDR - longest IPv6 address can be 45 character wide. While we may
> normalize the address and make it shorter. Question is whether we want
> it normalize here or exactly as we get it over wire.
>
> NETMASK - it is addr plus "/128" as longest prefix.
Today, we discussed another approach with Miroslav:
rhnServerNetInterface:
ID <-- this will be table's primary key
SERVER_ID
NAME
HW_ADDR
MODULE
CREATED
MODIFIED
rhnServerNetAddress4 (or some other / better name):
INTERFACE_ID <-- this will reference rhnServerNetInterface(id)
ADDRESS
NETMASK
BROADCAST
rhnServerNetAddress6 (or some other / better name):
INTERFACE_ID <-- this will reference rhnServerNetInterface(id)
ADDRESS
SCOPE
NETMASK
Plus we may have several other constraints in place, such as:
unique rhnServerNetAddress4(interface_id, address)
unique rhnServerNetAddress6(interface_id, address, scope)
Thoughts, concerns, suggestions?
-Milan Zázrivec
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Filters on reposync
Hi Michael,
Thanks a lot for your answer.
Regards.
Baptiste
- Mail original -
De: "Michael Mraka"
À: spacewalk-devel@redhat.com
Envoyé: Mardi 18 Octobre 2011 13:51:16
Objet: Re: [Spacewalk-devel] [PATCH] Filters on reposync
Baptiste AGASSE wrote:
% Hi,
%
% I've just looked at reposync.py code a I don't see any part related to
% getting include/exclude filters from database as properties of
% repositories that Jan asked me when i've submited some code for
% filters (he said that he didn't like that filters are specified at
% runtime).
%
% Any news on it ? If, you decide to store filters in database, these
% will be accessible through repositories webui ?
Hi Baptiste,
yesterday and today I finally saved some time to look into it again. I
added a database table to hold include/exclude filters and
spacewalk-repo-sync code which is able to use it. Unfortunately there's
not webUI part yet so if you want to check it you have to insert filter
data directy into database. E.g.
insert into rhncontentsourcefilter (id, source_id, sort_order, flag, filter)
values (sequence_nextval('rhn_csf_id_seq') , 536, 1, '+', 'samba-client');
where source_id is repository id (that's the end part as in
https:///rhn/channels/manage/repos/RepoEdit.do?id=536 url),
sort_order specifies the order of filters which belong to the same repo,
flag is either '+' or '-' (include / exclude) and filter is the list of
packages to be filtered.
Regards.
--
Michael Mráka
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] erratas and the client plugin package action
On 10/19/2011 11:59 AM, Miroslav Suchý wrote: > On 10/19/2011 09:45 AM, Simon Lukasik wrote: >> This is going to break Debian client. >> >> When something is moved from the rhn-client-tools to yum-rhn-plugin, it >> should be moved to apt-spacewalk as well. > > We use errata actions in Debian? > Well, we don't have a test for it. However, Until 561ee725dd0f6 we have distributed it. And no problem was reported so far. -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] erratas and the client plugin package action
On 10/19/2011 09:45 AM, Simon Lukasik wrote: > This is going to break Debian client. > > When something is moved from the rhn-client-tools to yum-rhn-plugin, it > should be moved to apt-spacewalk as well. We use errata actions in Debian? -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] erratas and the client plugin package action
On 10/18/2011 08:43 PM, Miroslav Suchy wrote: > Dne 18.10.2011 17:56, Ionuț Arțăriși napsal(a): >> Cool. So can you apply the patch that I attached to my previous email? > > Ahh, I did not notice it first time - sorry. Applied. Thanks. > > Mirek > This is going to break Debian client. When something is moved from the rhn-client-tools to yum-rhn-plugin, it should be moved to apt-spacewalk as well. -- Simon LukasikSystems Management QA sluka...@redhat.com #satellite-qa ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
