netcf ~ dependencies/versions
by Zdenek Styblik
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm wondering if somebody could provide me with, even rough, list of
possible dependencies for NetCF.
But actually it's not as important as versions of eg. libnl, libxslt,
libxml etc.
As for libnl, I hope NetCF is not based at libnl-2.0 as it is
incompatible with libnl-1.1 :s
Thanks,
Zdenek
- --
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0nZUwACgkQ8MreUbSH7imO2wCfVlWc/uz0Ro+e8UZo95YHlTJ7
7OwAoL+ssGYxQS49yHgWfF+YAEsbZk2o
=rbLs
-----END PGP SIGNATURE-----
13 years, 3 months
Re: [netcf-devel] [libvirt] Release of libvirt-0.8.7
by Laine Stump
(adding netcf-devel to the Cc list)
On 01/06/2011 10:02 PM, Patrick Mullaney wrote:
> On Thu, 2011-01-06 at 17:00 -0700, Jim Fehlig wrote:
>> Laine Stump wrote:
>>> As far as I know, the SuSE port was actually complete at one time, and
>>> was included in a released product (not sure what the product is),
>> It hasn't been included in a product yet, but might be in upcoming
>> openSUSE 11.4.
> Right. As far as I know, it should be in opensuse 11.4. I haven't
> heard otherwise. My plan was to upstream the patches but I got
> sidetracked with some other projects.
Ah, you're talking about a completely different effort - the SuSE port I
was talking about is referenced here:
https://fedorahosted.org/pipermail/netcf-devel/2009-June/000092.html
I pinged Jonas about it a couple months ago, and learned that they had
updated their patches and were actually using it (when I said "product",
I wasn't talking about the OS itself, but something based on the OS),
but hadn't had the resources to clean it up for upstream.
After searching the list archives for mail from Patrick, I now see this
message:
https://fedorahosted.org/pipermail/netcf-devel/2010-May/000415.html
(and a response from David Lutterkort), and even recall reading it, but
when I went through old mail in the Fall looking for people doing
porting work, I found the earlier messages from Jonas first and sent him
mail, then neglected to continue looking for other people working
separately on the same platform.
> My patches touch drv_initscripts.c, initscripts-get.xsl, and
> initscripts-put.xsl. The xsl files are slightly different because
> our ifcfg syntax is slightly different. I also have a couple new
> augeas lenses that we need for our network configuration to work.
> I'll try to apply it against head and send it out to the list soon.
It's good to hear that you've got it working. It will be nice when we no
longer have to tell so many people on #virt "well, if your distro had
netcf, you could do 'x', but since it doesn't, you'll need to do it by
hand".
> How would you recommend handling the files above and the build
> for different distros? Should they just be drv_suse.c,
> initscripts-get-suse.xsl, and initscripts-put-suse.xsl and then
> changed back during the build?
If the changes to drv_initscripts.c aren't too drastic, and can easily
be #ifdef'ed, I think it would be preferable to just keep the single
file there, to avoid maintenance problems with duplicated code; there's
nothing that says each supported platform needs its own drv_*.c file
(Fedora and RHEL already use drv_initscripts.c, for example).
If you think the changes are too big (maybe it ends up with 80% of the
file being inside #ifdefs), but there is still some common code, it
might be appropriate to move all the non-common things out of
drv_initscripts.c into drv_fedora-rhel.c, then have suse's build include
both drv_initscripts.c and drv_suse.c (likewise for fedora-rhel).
(For that matter, at that point, maybe drv_initscripts.c could be
renamed to dutil_initscripts.c (as long as there are no toplevel drv_*()
functions), and it could maybe get some of the functions from
dutil_linux.c that are really only applicable to initscripts-based systems.)
For the xsl files, I'm not really competent to render an opinion there.
I would say, though, that if it's possible to avoid duplicating
identical parts of those files (by some sort of conditionalizing in a
single file, or maybe splitting each file into a "common between all
initscripts platforms" and "specific to platform a", that would be
preferable. Otherwise, having separate files and copying them into
"initscripts-(get|put).xsl" during the build would be fine. (If you do
that, part of your patch should maybe be to move the current versions of
those files into "initscripts-fedora-rhel-(get|put).xsl", and add the
same build step to that port.)
There really are no hard/fast rules, though, as there is not yet any
precedent.
13 years, 3 months
Re: [netcf-devel] [libvirt] Release of libvirt-0.8.7
by Laine Stump
On 01/06/2011 02:03 PM, Zdenek Styblik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On 01/05/2011 04:43 PM, Laine Stump wrote:
>> On 01/05/2011 06:12 AM, Zdenek Styblik wrote:
>>
>> Zdenek - I'd be very happy to have a Slackware port of netcf, and would
>> be willing to help out getting it in (as long as you'd be willing to
>> help me setup a Slackware guest so I could test your patches ;-) There
>> have been 4 other people who started netcf ports (debian, arch linux,
>> suse, and (believe it or not, MS Windows)), but so far none has followed
>> through to actually pushing something into the main netcf git.
>>
> just wait a second; did you actually say "patches"? :) What is the
> original platform/distro of NetCF?
It was originally developed for Fedora and RHEL (RHEL5.x up to a point,
but now only RHEL6 support is up-to-date due to libnl version
incompatibilities on 5.x).
Because the network config files differ for different distros, there are
a couple of files that need to be different for each (or in some cases
where two distros are very close, maybe they can share the same source
files, with a few #ifdefs). The files defining the API, and implementing
the toplevel functions of the API should be common to all platforms, and
there is also a file of utility functions that should be useful on all
Linux platforms (but not on Windows).
As far as I know, the SuSE port was actually complete at one time, and
was included in a released product (not sure what the product is), but I
don't know where the source is (aside from earlier versions posted to
the list and available in the archives), and the developers haven't had
the resources available to clean it up and submit it back to the
upstream project. The debian and Windows ports have had patches posted
that were at the RFC level, but nothing committable yet. If I recall
correctly, the Arch Linux port was at the level of someone asking for
recommendations on how to proceed, but there haven't been any patches yet.
> It shouldn't matter if they've pushed changes or not as long as those
> are public somewhere.
Well, there is stuff in the mailing list archives, but it's all out of
date, because a couple months ago, based on problems revealed by the
Windows patches, I did some re-organizing of the files to better
separate the platform-specific stuff from the common stuff.
> Anyway, I gave it # ./configure; go and found out 'augeas', whatever
> that is, is "missing". And I expect more to come.
It's possible to make a netcf port that doesn't use augeas. The
Fedora/RHEL port uses it to parse all the separate
/etc/sysconfig/network-scripts/ifcfg-* files into something regular,
then convert that into the API-defined XML format, and to write changes
back to the ifcfg-* files (while maintaining the stuff in those files
that isn't affected by the changes).
The Fedora/RHEL port also uses libxslt2, and it would be possible to
make a port without that as well, although you likely will end up
wanting it, since it will make creating and parsing the XML required by
the API much simpler.
On Slackware, it looks like all the network config for all devices is in
a single file, */etc/rc.d/rc.inet1.conf
<http://www.slackware.com/config/network.php#rc.inet1>. To create a
Slackware port of netcf, you would want to write a drv_slackware.c that
implemented all the drv_*() functions declared in *internal.h (using
drv_initscripts.c as an example); if you don't want/need augeas to do
that, you won't need to link it in.
Of course there are some kinks - for example, I just noticed that,
although the intent is for the functions in util_linux.c to be useful on
all Linux platforms, there are several in there that are only useful if
you're using augeas (which maybe should be put into a new
util_augeas.c), and I also see that dutil.c (which was intended to be
useful on *all* platforms) #includes augeas.h, although it doesn't seem
to actually use any augeas functions (this is a leftover from old code,
and can likely just be removed).
> I can give it look over the weekend(no, I don't expect it to be done
> over the weekend - look :]).
Don't worry, I wouldn't expect that either - it's going to require
writing code that will transform the .INI file style info into XML, and
from XML back to the .INI style. Even with libxlt2, that isn't exactly
trivial (augeas can very likely help, though - it's very good at
grabbing a single value from a file and modifying it without screwing up
the rest of the file; so it's very likely you *will* want augeas, you'll
just use it differently).
> Slackware guest shouldn't be a problem. It's just like any other
> GNU/Linux. Setup partition, run setup, key stroke, key stroke, Install
> everything? [Yes], done :D j/k
>
> [...]
>> The first step would be to subscribe to the netcf-devel mailing list:
> Done.
>
>> I can help you out figuring out which bits need replacing for a
>> different platform (although I'm afraid I probably can't be much help
>> with what they should be replaced with :-)
> Sounds great. I probably should note I'm more like # ./configure&& make
> && ...&& makepkg; and some hack-n-slash person.
> It doesn't mean anything else than just making things clear(so much for
> expectations) :)
>
13 years, 3 months