You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(44) |
Nov
(18) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(12) |
Feb
(5) |
Mar
(8) |
Apr
(51) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(8) |
Oct
(1) |
Nov
(53) |
Dec
(17) |
2004 |
Jan
(20) |
Feb
(18) |
Mar
(11) |
Apr
(2) |
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
2007 |
Jan
(1) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Richard S. <csa...@ui...> - 2004-03-08 09:36:30
|
Ups, I forgot to reply to the list. =2DRichard =2D--------- Weitergeleitete Nachricht ---------- Subject: Re: [Config4gnu-developer] New Architecture+WBEM Stuff Date: Montag 08 M=E4rz 2004 07:12 =46rom: Richard Spindler <csa...@ui...> To: Justin Yackoski <ju...@sk...> Zitat von Justin Yackoski <ju...@sk...>: > On 04 Mar 2004 11:51:29 +0100 > > Richard Spindler <csa...@ui...> wrote: > > Hi, > > I have I little Question concerning the future Direction of CFG. > > > > > > Will it be possible with the new architecture, to have full local > > access to the CFG System without the need to run a > > WBEM/CIM/Whatever-Server? > > Do you mean using the fancy GUI or do you just mean being able to have so= me > sort of interface to CFG (an API or script-accessible way to get at ALL t= he > data)? If you're referring to the first case, no. If its second case, > well, script-accessiblity and an API will satisfy all my needs. > under the proposed method our data will be natively stored in WBEM/CIM > format, so you'll either need to speak that or we may have an alternate > XML-based format, but I don't know how exactly we'd describe our XML > format... right now we use our type definitions, Jason how would we do th= is > in the new model? =2DRichard =2D------------------------------------------------------ |
From: Justin Y. <ju...@sk...> - 2004-03-07 23:47:15
|
On 04 Mar 2004 11:51:29 +0100 Richard Spindler <csa...@ui...> wrote: > Hi, > I have I little Question concerning the future Direction of CFG. > > > Will it be possible with the new architecture, to have full local > access to the CFG System without the need to run a > WBEM/CIM/Whatever-Server? Do you mean using the fancy GUI or do you just mean being able to have some sort of interface to CFG (an API or script-accessible way to get at ALL the data)? If you're referring to the first case, no. If its second case, well, under the proposed method our data will be natively stored in WBEM/CIM format, so you'll either need to speak that or we may have an alternate XML-based format, but I don't know how exactly we'd describe our XML format... right now we use our type definitions, Jason how would we do this in the new model? -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
From: Jason L. <JL...@me...> - 2004-03-05 22:15:20
|
Ok thanks for noticing this problem... I've committed the fix, but it may take a while to see it on the anonymous CVS servers. Jason >>> or...@m7... 3/2/04 4:04:36 AM >>> The following file seems to be missing in the AC_OUTPUT Section in configure.in: src/providers/CFG/SOAP/Makefile (I'm using the c4g Version from Anonymous-CVS) -Richard ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
From: Richard S. <csa...@ui...> - 2004-03-04 10:55:28
|
Hi, I have I little Question concerning the future Direction of CFG. Will it be possible with the new architecture, to have full local access to the CFG System without the need to run a WBEM/CIM/Whatever-Server? -Richard |
From: C. G. <c.g...@tu...> - 2004-03-02 12:08:07
|
Hi, I gathered some more information and put it up on the freedesktop.org page. Please review. (also the FAQs) http://freedesktop.org/Main/CFG Regards, Christian |
From: Richard S. <or...@m7...> - 2004-03-02 09:07:51
|
The following file seems to be missing in the AC_OUTPUT Section in configure.in: src/providers/CFG/SOAP/Makefile (I'm using the c4g Version from Anonymous-CVS) -Richard |
From: C. G. <c.g...@tu...> - 2004-02-24 19:10:13
|
> By the way, what distribution are you using? I have a box with suse 9.0 here to play around with. I got past the missing pkgconfig, but seems like it only comes wth sigc++ 1.0 and libgtkmm-1.2. cheers, Christian |
From: Jason L. <JL...@me...> - 2004-02-24 16:28:50
|
Ok, this syntax error appears to be related to the pkgconfig program. Basically, the PKG_CHECK_MODULES isn't defined in the aclocal.m4 file, which is generated when you run ./autogen.sh. On my system, the PKG_CHECK_MODULES is found in /usr/share/aclocal/pkg.m4 and copied into aclocal.m4 when I run ../autogen.sh. It may be that you don't have pkg-config installed. If this is the case, simply install pkgconfig and rerun ./autogen.sh. If you do have pkg-config installed, it may be in an unusual installation prefix. If this is the case, find out where the pkg.m4 file is, and do the following... Edit autogen.sh. Add a -I option to the aclocal command, giving it the path to the directory containing the pkg.m4 file. E.g. aclocal -I /usr/share/aclocal By the way, what distribution are you using? Jason >>> c.g...@tu... 2/24/04 10:56:16 AM >>> Jason Long wrote: > The following steps should let you build without PHP: > 1. Edit configure.in. Comment out the line containing cfg_PHP_CFLAGS. > I.e. make it like this: > # cfg_PHP_CFLAGS > 2. Edit src/wrappers/Makefile.am. Remove php from the SUBDIRS = line. > I.e. make it like this: > SUBDIRS = perl5 > 3. Rerun ./autogen.sh. Thank you Jason, I followed your recomendaton. It looks better, no php checks anymore, unfortunately it still keeps complaining about a syntax error: ../autogen.sh --with-xerces-c-root="/usr" [...] checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag "F77" to libtool checking for Xerces-C++ library... found checking for perl... /usr/bin/perl checking for Perl version >= 5.004... yes checking for Perl include files... -I/usr/lib/perl5/5.8.1/ i586-linux-thread-multi/CORE ../configure: line 18412: syntax error near unexpected token `LIBCFGDOM,' ../configure: line 18412: `PKG_CHECK_MODULES(LIBCFGDOM, libxml-2.0 glib-2.0 gobject-2.0)' > Jason > Christian ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
From: C. G. <c.g...@tu...> - 2004-02-24 15:35:09
|
Jason Long wrote: > The following steps should let you build without PHP: > 1. Edit configure.in. Comment out the line containing cfg_PHP_CFLAGS. > I.e. make it like this: > # cfg_PHP_CFLAGS > 2. Edit src/wrappers/Makefile.am. Remove php from the SUBDIRS = line. > I.e. make it like this: > SUBDIRS = perl5 > 3. Rerun ./autogen.sh. Thank you Jason, I followed your recomendaton. It looks better, no php checks anymore, unfortunately it still keeps complaining about a syntax error: ./autogen.sh --with-xerces-c-root="/usr" [...] checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag "F77" to libtool checking for Xerces-C++ library... found checking for perl... /usr/bin/perl checking for Perl version >= 5.004... yes checking for Perl include files... -I/usr/lib/perl5/5.8.1/ i586-linux-thread-multi/CORE ./configure: line 18412: syntax error near unexpected token `LIBCFGDOM,' ./configure: line 18412: `PKG_CHECK_MODULES(LIBCFGDOM, libxml-2.0 glib-2.0 gobject-2.0)' > Jason > Christian |
From: Jason L. <JL...@me...> - 2004-02-24 14:33:53
|
Let's see... here's what it looks like the php configure arguments do: --disable-php this effects whether to build the PHP client found in src/clients/php. Since that client doesn't get compiled or installed anyway, this flag currently has no real effect. --with-php-config this switch specifies the location of php-config in case the configure script can't find it on its own. Apparently there is no way to disable building the PHP wrappers. This is a bug. The following steps should let you build without PHP: 1. Edit configure.in. Comment out the line containing cfg_PHP_CFLAGS. I.e. make it like this: # cfg_PHP_CFLAGS 2. Edit src/wrappers/Makefile.am. Remove php from the SUBDIRS = line. I.e. make it like this: SUBDIRS = perl5 3. Rerun ./autogen.sh. Jason >>> c.g...@tu... 2/21/04 6:43:18 AM >>> Hello, trying to compile the cvs version configure stopped. I think I could find most dependecies even xerces in stock suse 9.0. Since I did not want the php module I attempted to disable it. I could get rid of the command not found warning by comenting out all php checks, but the syntax error remained. Christian This is the output: ~/cfg/config4gnu> ./autogen.sh --with-xerces-c-root="/usr" --disable-php --without-php-config Adding libtool. Building macros. Building makefiles. configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' Makefile.am: installing `./COPYING' src/clients/cfgconsole/Makefile.am: installing `./depcomp' Building configure. Running configure. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking build system type... i686-suse-linux checking host system type... i686-suse-linux checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/i586-suse-linux/bin/ld checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes checking for /usr/i586-suse-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fl32... no checking for af77... no checking for fort77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for lf95... no checking for g95... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/i586-suse-linux/bin/ld checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag "F77" to libtool checking for Xerces-C++ library... found checking for perl... /usr/bin/perl checking for Perl version >= 5.004... yes checking for Perl include files... -I/usr/lib/perl5/5.8.1/ i586-linux-thread-multi/CORE checking for PHP include files... ./configure: line 1: no: command not found checking for PHP extension directory... ./configure: line 1: no: command not found configure: WARNING: Cannot write to ../configure: line 18508: syntax error near unexpected token `LIBCFGDOM,' ../configure: line 18508: `PKG_CHECK_MODULES(LIBCFGDOM, libxml-2.0 glib-2.0 gobject-2.0)' ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
From: C. G. <c.g...@tu...> - 2004-02-21 11:20:31
|
Hello, trying to compile the cvs version configure stopped. I think I could find most dependecies even xerces in stock suse 9.0. Since I did not want the php module I attempted to disable it. I could get rid of the command not found warning by comenting out all php checks, but the syntax error remained. Christian This is the output: ~/cfg/config4gnu> ./autogen.sh --with-xerces-c-root="/usr" --disable-php --without-php-config Adding libtool. Building macros. Building makefiles. configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' Makefile.am: installing `./COPYING' src/clients/cfgconsole/Makefile.am: installing `./depcomp' Building configure. Running configure. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking build system type... i686-suse-linux checking host system type... i686-suse-linux checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/i586-suse-linux/bin/ld checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes checking for /usr/i586-suse-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fl32... no checking for af77... no checking for fort77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for lf95... no checking for g95... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/i586-suse-linux/bin/ld checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag "F77" to libtool checking for Xerces-C++ library... found checking for perl... /usr/bin/perl checking for Perl version >= 5.004... yes checking for Perl include files... -I/usr/lib/perl5/5.8.1/ i586-linux-thread-multi/CORE checking for PHP include files... ./configure: line 1: no: command not found checking for PHP extension directory... ./configure: line 1: no: command not found configure: WARNING: Cannot write to ./configure: line 18508: syntax error near unexpected token `LIBCFGDOM,' ./configure: line 18508: `PKG_CHECK_MODULES(LIBCFGDOM, libxml-2.0 glib-2.0 gobject-2.0)' |
From: C. G. <c.g...@tu...> - 2004-02-19 11:49:41
|
Thank you for explaining some of the issues involved, Justin. > > What was the reasoning to slide WBEM right into the heart of CFG? ;-) > > I think there were 2 main reasons for putting it right in. First, we don't > want to depend on Xerces anymore. Second, if we used another XML library, > then we'd essentially be generating XML in our bottom/middle layer, > converting it to WBEM/CIM, which in turn would convert it to XML for remote > communication I thought CIM over XML is only optional and not necessarily needed on this level. (Only beneficial for WBEM clients.) Installers, package managers, scipts etc. have a need for comand line config tools and serialized config data. They should not even need to use a full blown xml library to make use of CFG, and I don't think local command line tools would like to depend on any remote configuration protocol. > we'd really only need to do the XML -> WBEM/CIM > conversion which might not be too hard. Yes, expecially compared to the many config file -> WBEM/CIM conversions that when hooking WBEM directly into the parsers. Parsing CFGs xml doesn't seem to be that much of a difference from parsing a config file. Just that it literally parses all cfg supported config files. > Also, we didn't want to have the > C++ <-> perl communication as only very recent gcc compilers don't have a > bug that causes issues w/ it. Ok, hopfully recent gcc versions will become mainstream quickly. As the main constrain for CFG at the moment seems to be the time available for it, it will probably have to stay for a while like it is. I'd find it really unfortunate though, if the original intention to improve the "nightmare" of Linux/Unix configuration would be buried in the meantime. Kind Regards Christian Jason: Maybe cfengine might also be interesting four you if you have to administer a bunch of boxes. (not knowing anything about your setup though) |
From: Justin Y. <ju...@sk...> - 2004-02-19 04:04:22
|
On Wed, 18 Feb 2004 23:42:44 +0100 "C. Gatzemeier" <c.g...@tu...> wrote: > > Jason wrote: > > 2. Indeed, in my job I administer many servers, of various flavors > > of Linux/Unix and other operating systems. It is my intention to > > make Config4GNU into something I can use on my job, and if I can't > > do remote management with Config4GNU, it's useless. With WBEM, I > > have a network protocol, client/server components, and > > authentication already built. > > Oh, good news that there is a little itch, too ;-) And I am absolutely > not oposed if you want to use WBEM or any other protocol. I would just > be a little disappointed if this would need to be done forking away > from the CFG framework and/or introduce things that would make CFG > less appealing for standard use in distributions. > > > What do you guys think of this slightly modified diagram for remote > access _to_ CFG in this case with WBEM: > > > +-----------------------+ > | WBEM Client | > +-----------------------+ > | CFG Client Library | <--- optionally, is it needed at all? CFG > aware+-----------------------+ clients just request full > xml-representation| WBEM library | --------- > +-----------------------+ | > | | > +--CIM over XML protocol--+ | is "over XML" necessary? > | |- Existing code (OpenWBEM, > +-----------------------+ | OpenPegasus, etc.) > | CIMOM | | > +-----------------------+ | > | Perl Provider IFC | --- > +-----------------------+ > | Perl Provider Scripts | > +-----------------------+ > | CFG xml-rep. Parser | > +-----------------------+ > > This way the part above is an optional top layer add-on to the > existing CFG system: > > +-----------------------+ --- CFG will provide many > | CFG middlelayer | |- meta-data driven parsers > +-----------------------+ | > | Backend Parsers | --- > +-----------------------+ > > > A quick "remote features for CFG with WBEM" hack could just tunnel the > xml representation through the WBEM protocol. Translating CFG entities > into regular WBEM objects for arbitrary WBEM clients could follow > later. > > What was the reasoning to slide WBEM right into the heart of CFG? ;-) I think there were 2 main reasons for putting it right in. First, we don't want to depend on Xerces anymore. Second, if we used another XML library, then we'd essentially be generating XML in our bottom/middle layer, converting it to WBEM/CIM, which in turn would convert it to XML for remote communication, and then it would be converted back to WBEM/CIM for the client programs (which could optionally re-convert it to XML again). That may not be a huge performance hit, and WBEM does a lot of the converting for us, we'd really only need to do the XML -> WBEM/CIM conversion which might not be too hard. Also, we didn't want to have the C++ <-> perl communication as only very recent gcc compilers don't have a bug that causes issues w/ it. If the bottom/middle layer were written entirely in perl and used a common, perl-based XML library, I think these issues could be addressed. This solution is actually more or less exactly a solution I proposed, and could probably do the job. > > Justin wrote: > > From a design perspective, I think the major negative > > on this is that we'd have to maintain *2* copies of meta-data. One > > for WBEM/CIM and one for our XML system. > > I am not sure why this should be the case, please explain a little > more. Well, we'd need our CFG type-definition meta-data objects to be created & maintained and we'd also need CIM object definitions to be created and somehow maintained. If fiddling with the CIM object definitions required any regular human interaction, it would be a huge resource drain. If we could get a good conversion script to make CIM objects for our type definitions, then this isn't an issue. I'm sure it'd be possible. > I kept thinking a bit about remote fetching from the backend i.e. > simple ssh fetching (not to replace WBEM only as another way). I find > it increasingly interersting to have the possibility to let the > backend parse remote machine's configs through ssh without the need to > install anything additional on other machines. Remote application > specific meta-definitions (if present say in > /usr/share/cfg-definitions/*.cfg) could override local ones for remote > > files. (Just in case if versions or locations differ (for example on > another distribution)) > And those nodes would again show up in all CFG frontends. > Same should work with WBEM or LDAP parsers for CFG. What do you think > about this? That would be a good alternate remote system in addition to WBEM. I could certainly see a need to add capability underneath our WBEM providers to grab remote machine's configuration if they don't have WBEM/CFG installed. This would be a *very* nice feature for some people managing large numbers of PCs, some of which may not support CFG for one reason or another (although if the bottom of CFG was written purely in perl and the WBEM system we choose supports their OS...) . In the end, I'm really not sure which way is better & easier as far as development goes. The solution you propose seems more elegant and I think retains maybe a little more of the original CFG design. I don't know if thats necessarily a good thing or not. It would definitely provide more flexibility with only some minor adjustments in the overall architecture, and remove a complete dependence on WBEM. Actually, I could see an eventual need for some sort of original CFG-based XML system to allow scripted tasks to run (i.e., during OS installation) without requiring a functional WBEM server & the whole works. You certainly raise some good points. -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
From: C. G. <c.g...@tu...> - 2004-02-18 22:35:52
|
Jason wrote: > 2. Indeed, in my job I administer many servers, of various flavors of > Linux/Unix and other operating systems. It is my intention to make > Config4GNU into something I can use on my job, and if I can't do remote > management with Config4GNU, it's useless. With WBEM, I have a network > protocol, client/server components, and authentication already built. Oh, good news that there is a little itch, too ;-) And I am absolutely not oposed if you want to use WBEM or any other protocol. I would just be a little disappointed if this would need to be done forking away from the CFG framework and/or introduce things that would make CFG less appealing for standard use in distributions. What do you guys think of this slightly modified diagram for remote access _to_ CFG in this case with WBEM: +-----------------------+ | WBEM Client | +-----------------------+ | CFG Client Library | <--- optionally, is it needed at all? CFG aware +-----------------------+ clients just request full xml-representation | WBEM library | --------- +-----------------------+ | | | +--CIM over XML protocol--+ | is "over XML" necessary? | |- Existing code (OpenWBEM, +-----------------------+ | OpenPegasus, etc.) | CIMOM | | +-----------------------+ | | Perl Provider IFC | --- +-----------------------+ | Perl Provider Scripts | +-----------------------+ | CFG xml-rep. Parser | +-----------------------+ This way the part above is an optional top layer add-on to the existing CFG system: +-----------------------+ --- CFG will provide many | CFG middlelayer | |- meta-data driven parsers +-----------------------+ | | Backend Parsers | --- +-----------------------+ A quick "remote features for CFG with WBEM" hack could just tunnel the xml representation through the WBEM protocol. Translating CFG entities into regular WBEM objects for arbitrary WBEM clients could follow later. What was the reasoning to slide WBEM right into the heart of CFG? ;-) Justin wrote: > From a design perspective, I think the major negative > on this is that we'd have to maintain *2* copies of meta-data. One for > WBEM/CIM and one for our XML system. I am not sure why this should be the case, please explain a little more. I kept thinking a bit about remote fetching from the backend i.e. simple ssh fetching (not to replace WBEM only as another way). I find it increasingly interersting to have the possibility to let the backend parse remote machine's configs through ssh without the need to install anything additional on other machines. Remote application specific meta-definitions (if present say in /usr/share/cfg-definitions/*.cfg) could override local ones for remote files. (Just in case if versions or locations differ (for example on another distribution)) And those nodes would again show up in all CFG frontends. Same should work with WBEM or LDAP parsers for CFG. What do you think about this? Christian |
From: C. G. <c.g...@tu...> - 2004-02-12 23:18:21
|
Just wanted you to know it is good to hear from you, some very interesting points, unfortunately I can not look into it more before next week. later, Christian |
From: Jason L. <JL...@me...> - 2004-02-11 20:10:27
|
Here are just a few of my thoughts: 1. I don't think the CIM spec is as limited as you guys are making it out to be. Yes, CIM currently cannot do properties of complex data types, and to implement hierarchies you'd need to use associations to create parent/child relationships between the objects. However, for complex properties you could always use "string" properties to pack more complicated data (even XML) if needed, and CIM has "qualifiers" that allow you to describe additional semantics for each property, such as enumerated values, range of acceptable values, and human-readable descriptions. Furthermore, the use of associations allow you to connect different CIM objects in all sorts of ways (not just parent/child relationships), and the CIM objects you're connecting don't even need to be objects on the same server. In fact, what I envision is a person who administers many servers connects to a particular WBEM server, and on this WBEM server there are links to all the different CIM objects on all the different servers that represent the many things that can be configured/managed. So you see, you can still create a group for "servers" and a group for "workstations" and create entities underneath them to represent the things that can be configured. 2. Indeed, in my job I administer many servers, of various flavors of Linux/Unix and other operating systems. It is my intention to make Config4GNU into something I can use on my job, and if I can't do remote management with Config4GNU, it's useless. With WBEM, I have a network protocol, client/server components, and authentication already built. If I wasn't so concerned about getting a satisfactory remote management scenario working, I'm sure I would see things differently. In addition, I'm not interested in investing the amount of personal time it would take to create our own protocols, authentication schemes and then implement them all in the current codebase. -- In other news... Configuring Samba through the new WBEM-enabled code is largely working. There are a few aspects on the parser side that are still broken, and the client-side forms are all currently hard-coded, but I think I can do anything I want to with an smb.conf file through the Config4GNU software now. This includes adding/removing properties on shares, adding/removing shares themselves, setting global properties and default share settings. Oh, and you can do it on a remote computer too. Screenshots are available at http://jason.long.name/config4gnu-wbem/screenshots.html. (You may want to ignore the Nagios screenshots unless you are also interested in the Nagios provider.) Source code for the various components have been imported into the Sourceforge CVS servers. Check out the modules owperlprovider, config4gnu-wbem, and cimbrowser. There are also tarballs and installation instructions available at http://jason.long.name/config4gnu-wbem/index.html. Jason |
From: Justin Y. <ju...@sk...> - 2004-02-11 03:49:26
|
On Mon, 9 Feb 2004 14:34:45 +0100 "C. Gatzemeier" <c.g...@tu...> wrote: > I understand that since I was not so conviced about the proposed > changes I need to try to show an alternative. So here I'll try. I really appreciate your feedback, I'll admit that I'm not completely convinced that WBEM is the best technological/design-based direction, but I'm fairly convinced that it is the best overall decision for the CFG project. I'm all for whatever will help CFG the most, which may or may not be what Jason and I initially decide on. > I like the schematic given at > http://config4gnu.sourceforge.net/docs/schematic.html > Maybe just the authentication, remote administration, and > backup/restore needs to be moved one layer up to avoid unnecessary > difficulties. This is also a sticking point for me. The main advantages that WBEM/CIM gives us are remote administration and a sort-of abstract configuration editing system to build upon. Is the CIM spec more limiting than our XML data model, yes, absolutely. Will it always be, I hope not. > The middlelayer provides a common representation in XML with addiional > > features and logic. > This is CFGs main thing, providing a good and unified abstraction of > the configuration. Everything else gets much easier when build on > that. It's ok to hand XML back an forth as long as it is going to be > used localy, it is just analogous to opening the config files > directly. > > Alternative interfaces can be build on that CFG representation and > constitute new parts of the "CFG top layer" WBEM and LDAP seem to be > of particular interest here. On the other hand a CFG bottom layer LDAP > parser would also be very interesting for systems that have part of > their config stored in LDAP directories. > > For the XML representation there should never be a need to make it > accessible from remote from within CFGs middle layer. As the name says > it is just a representation of the config files with the same access > restrictions (bound to the user calling CFG). This is very true. From a design perspective, I think the major negative on this is that we'd have to maintain *2* copies of meta-data. One for WBEM/CIM and one for our XML system. If we could create a near-flawless translation layer, then this is a moot point. I think examining how possible that is would be a worthwhile experiment. > For remote adminstration I picture remote config files could be > included into the CFG representation with a "include" in the > config4gnu.xml meta-definition that points to them. CFG could open a > ssh connection to that machine and remote config files and > meta-definitions can be parsed. > > This first case wouldn't even require CFG being installed on remote > machines and would be a simple direct interactive operation. Agreed, this would be possible, and potentially easier to use. However, WBEM may soon be as commonly installed on a server as SSH is today. WBEM potentially gives us more advanced features over SSH, with little effort on our part. I think this really is the crux of the matter, the amount of work. Successfully using WBEM really depends on 2 assumptions. The first is that any features WBEM is severely lacking will be added in the near future. The second is that WBEM will soon be widely-used. Will this happen? Its hard to say. From my limited exposure to it, WBEM seems to be a reasonable cut at a first version of a protocol. It definitely should have more features. Ironically, it seems WBEM would be more useful if it were more like XML (hierarchical and more extensible). Either way, CFG does need some architectural reworking, and WBEM seems a convenient component to slide in the middle of our system that we want and need to better separate. I think the difficulty is integrating WBEM into our system only as much as we need to, in the event that WBEM turns out to not be the best approach. If we had unlimited programmers working on CFG, I think closely integrating WBEM into our system (as opposed to providing a WBEM API, in addition to our normal API) would not be as good of an idea. I'd really like to hear any suggestions on how to change that proposed diagram of our system (in the email Jason posted to the list) so that we can avoid writing code that does exactly what WBEM does and be able to maintain our internal XML architecture. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
From: C. G. <c.g...@tu...> - 2004-02-09 13:09:27
|
Hello, I understand that since I was not so conviced about the proposed changes I need to try to show an alternative. So here I'll try. In my eyes CFG is a important joining piece that is needet to bring unix systems and higher level interfaces (GUIs protocolls etc.) together in a consistent way. So one point is to make it scale easily and modular from small to large and not include too much too fast. I like the schematic given at http://config4gnu.sourceforge.net/docs/schematic.html Maybe just the authentication, remote administration, and backup/restore needs to be moved one layer up to avoid unnecessary difficulties. The middlelayer provides a common representation in XML with addiional features and logic. This is CFGs main thing, providing a good and unified abstraction of the configuration. Everything else gets much easier when build on that. It's ok to hand XML back an forth as long as it is going to be used localy, it is just analogous to opening the config files directly. Alternative interfaces can be build on that CFG representation and constitute new parts of the "CFG top layer" WBEM and LDAP seem to be of particular interest here. On the other hand a CFG bottom layer LDAP parser would also be very interesting for systems that have part of their config stored in LDAP directories. For the XML representation there should never be a need to make it accessible from remote from within CFGs middle layer. As the name says it is just a representation of the config files with the same access restrictions (bound to the user calling CFG). For remote adminstration I picture remote config files could be included into the CFG representation with a "include" in the config4gnu.xml meta-definition that points to them. CFG could open a ssh connection to that machine and remote config files and meta-definitions can be parsed. This first case wouldn't even require CFG being installed on remote machines and would be a simple direct interactive operation. For a little more sofisticated distribution setup different sets of config files stored localy on the configuration server could be included into CFGs representation classes. For now lets assume they are edited with CFG on the sever. On the cliens a CFG utility periodically (or upon startup and change notification) fetches the XML representations "clients" class (included files get transfered from the server in the same way as in the first case) and merges changes into the "local computer" representation class. Best Regards, Christian |
From: C. G. <c.g...@tu...> - 2004-02-07 14:50:24
|
Hi, I'd like to add my two cents sice I was impressed so much about the concepts in CFG so far. > [We] are concerned with some of the problems that the current > code has. These include problems with dependencies, and architectural > difficulties with passing XML back and forth. I recognize the issues but somehow I don't think the pictured way is the apropriate solution. IMHO introducing WBEM, CIMOM and CIM over XML will first of all bring more dependencies and as you described additionally seems to be also a fairly limited protocoll for us to build on. Many additions itroducing complexity all over the place seem to be needed. The fact that it might be an established standard with existing clients that can conect might be tempting, but FWIW I think a CFG "top layer interface" as mentioned here before that provides WBEM is better suited for that than running CFG entirly over WBEM. What about next year when the next config protocoll comes around? Concerning the benefits of an extra configuration protocol. Does remote access to CFG need to require more than a ssh connection? Is another open port really always neccessary? I am not convinced. I thought that it is the beauty of the unix-way to practically combine and use existing facilities. Same for access rights to the configuration data, they are already handled by the filesystem. When thinking of remote administration of computers simply accassing individual machines doesn't cut it, I think. That is one thing why I was so positive about CFG with its middlelayer before, assuring a common consistent representation to all frontends. Configuration entities where put into a hierarchie of different classes. At this point only "computer" existed but I alread pictured to devfine classes like "servers" or "workstations" that could be configured in one swoop. Propagating of the files (push/pull ?) possibly done by some other system like FAI or cfengine or plain mounting of remote filesystems. Or a cfg "remote machine parser" could open a ssh connection and fetch/writeback files. (All run with user privileges with the option to "su") Without the middlelayer CFG is not that much different than other tools like libconf. The distribution independence relies heavily on this common abstracion layer where all systems look alike. And I guess it is much harder to convince people that having their frontend depend on WBEM + cfg enhancements, CIM (over XML), and a cfg-client lib is just as nice. So to summarize, I think we coould be able to figure out a even more universal way to reduce dependencies and to tackle the problems, including providing WBEM support but without putting to much restraint on cfg's future in the "unix-way". Regards, Christian |
From: Jason L. <JL...@me...> - 2004-02-04 14:30:56
|
Justin and I finally had a sort of planning meeting to discuss our intentions with Config4GNU. Both of us are still interested in working on the project, but are concerned with some of the problems that the current code has. These include problems with dependencies, and architectural difficulties with passing XML back and forth. I, of course, being interested in WBEM, advocated looking further into using WBEM as a client/server communication protocol and even using WBEM's object model (called CIM) to express configuration data. This approach is going to have both advantages and disadvantages. Advantages include being able to leverage existing WBEM management clients, not having to develop our own client/server protocols and authentication mechanisms, and simplifying the code. The disadvantage is that CIM's object model is not hierarchical, which makes a lot of our XML-based object code useless with CIM. Here are some of the results of our discussion: 1. We decided to pursue the WBEM direction. 2. A WBEM architecture would look something like this: (Please view in a monospace font for this to look correctly.) +-----------------------+ CFG will provide 1 or more clients | Clients | <--- driven by client meta-data +-----------------------+ | CFG Client Library | <--- shared code that uses CFG-specific +-----------------------+ client meta-data to enhance clients | WBEM library | --------- +-----------------------+ | | | +--CIM over XML protocol--+ | | |- Existing code (OpenWBEM, +-----------------------+ | OpenPegasus, etc.) | CIMOM | | +-----------------------+ | | Perl Provider IFC | --- +-----------------------+ | Perl Provider Scripts | +-----------------------+ --- CFG will provide many | CFG Parser library | |- meta-data driven parsers +-----------------------+ | | Individual Parsers | --- +-----------------------+ 3. The parser layer(s) are written in Perl and are independent of the above layers... i .e. no CIM objects used. This allows command line tools on the local system to interact with configuration data without the use of the CIMOM. 4. The use of metadata will still be something about Config4GNU that sets it apart from other projects. There are two types of metadata: client-side and parser-side. Client-side metadata consists of translated property names, descriptions, and details like how to present data. They will be stored in the CIM schema (.mof files) and in client-side form files, wizards, and plugins. Parser-side metadata consists of configuration-file mechanisms, and will currently be stored directly in the parsers in Perl code. Once enough parsers have been written to determine what sort of parser-side metadata is common, it will be moved into external data files (e.g. in XML format). CFG will also serve as a central repository for client and parser meta-data, similar to CPAN, Rpmfind, etc. Since we hope that distros and software authors may help by writing and customizing meta-data, this will be taken into account by our design. This is intended to aide in the distribution and sharing of meta-data, and not to serve as a point of control. So what this means for our current code/features is: 1) The majority of our parsers will be usable as-is, the migration to WBEM will occur mostly in the existing parser library. 2) Our client API will be based on WBEM with optional enhancements. Normal WBEM clients will be able to work with our providers to manipulate configuration data, but additional meta-data will be availble to make CFG-enabled WBEM clients much more robust and flexible. Existing CFG clients will require some changes. CFG-enabled clients will fully support WBEM and also use a client-side library for CFG-specific tasks. 3) Our "middle layer" will be nicely replaced with WBEM. Our new parser layer's library will become responsible for additional tasks previously managed by our middle layer ( revision control, privilege elevation, etc.) The client(s) we write will also take on additional duties via a library. Essentially, we now have a more established client and server side middle layer. Configuration data validation will be performed both by the client and parser layers where applicable. 4) Remote configuration editing will be, by default, possible. This is a huge benefit to CFG, as WBEM/CIMOM handles many difficult things for us. 5) Local configuration, especially during system installation, will be accessible for scripting purposes both via a CIMOM server and via a basic interface which will plug directly into our parser layer. This will allow scripts to work just as they did before, and also provide a way to dump configuration representations (in XML or some other easy to parse/manipulate format). Basically, we aren't aware of any features we won't be able to handle, and for the cost of switching in WBEM, we gain significant progress that will help us focus on our specific goals. What will still make CFG unique is: 1) Our clients and parses will be meta-data driven. While much of our data's structure will now be found in CIM object structures, much still remains that we will add. We will strive to be the best/easiest system to add configuration capabilities to, just as before. 2) We will work to help pool resources and reduce duplication of work. Supporting WBEM, a configuration-editing standard, will facilitate this. What we aim to do in the next month or two: 1) better define needed roles in the CFG project to help encourage others to participate and better recognize those who already do 2) Get a basic prototype working 3) Create a draft of what a WBEM-enabled client will provide that regular WBEM clients don't 4) Convert the parser library to a WBEM-provider. 5) Determine what meta-data should go in CIM, the client meta-data, and the parser meta -data. Jason Long |
From: Jason L. <JL...@me...> - 2004-02-02 19:52:41
|
Justin and I (the two main founders of the project) recently had a meeting to discuss future directions for Config4GNU. I or him will be posting shortly what we discussed.... so hang tight until then. Jason >>> pi...@so... 1/29/04 9:16:52 PM >>> Hi guys, I have started a KDE configuration tool but it seems harder than I expected :) I did the bad choice to think a filesystem-like view would be a good idea, but I discovered the "folders" can have several properties... so using the kio_slaves way is not a good solution probably. I tried the expand method of the CfgObject => does not seems to work :( I will try with the CVS version soon. Furthermore, I successfully compiled the gtkmm configuration tool, but it crashes everytime at launch. I will install gtk with debug symbols if I am strong enough. Anyway, a friend of mine would like to contribute as well maybe, I am trying to convince him. A first step would be to add comments in the code I think, it would be a good idea even if the names of the methods are explicit :) I will try to add some comments while looking further in the code and I will send you my patches. My friend will probably join as well, so tell us what parts of the lib need work since you will have more manpower. What are your plans ? Feel free to contact me by IM as well: bad...@ja... Best Regards. Pierre Souchay ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
From: C. G. <c.g...@tu...> - 2004-02-01 13:38:04
|
Am Sonntag, 1. Februar 2004 14:02 schrieb Pierre SOUCHAY: > > Please check out the new page at http://freedesktop.org/Main/CFG > But: > > Forbidden > You don't have permission to access /bin/view/Main/CFG on this server. So you can't even open the page? Or is that just when you want to edit it? |
From: Pierre S. <pi...@so...> - 2004-02-01 13:02:01
|
C. Gatzemeier wrote: > Hi, > > Please check out the new page at http://freedesktop.org/Main/CFG A good thing ! But: Forbidden You don't have permission to access /bin/view/Main/CFG on this server. Apache/1.3.29 Server at freedesktop.org Port 80 Note: I have this problem on many pages on fd.o website. > > And give it a try to edit and add to them. > > All the best, > Christian |
From: C. G. <c.g...@tu...> - 2004-02-01 12:53:42
|
Hi, Please check out the new page at http://freedesktop.org/Main/CFG And give it a try to edit and add to them. All the best, Christian |
From: <p.c...@ar...> - 2004-01-31 21:03:00
|
Hi, > My friend will probably join as well, so tell us what parts of the lib > need work since you will have more manpower. Great, you are very welcome! > > What are your plans ? IIRC everybody agreed that some preparation to pitch a release would be needed but there should also be a little list in the list archive, if sf.net did not drop that one. (gmane.org has only an achive since 12/03 at this point) Some Bugs/RFEs could also give an idea. cheers, Peter |