Re: [Vserver] packaging review for new Debian packages

2004-12-29 Thread Kilian Krause
Hi Enrico,

Am Dienstag, den 28.12.2004, 03:49 +0100 schrieb Enrico Scholz:
  [ ... util-vserver.spec ...]
   Sounds like maybe it shouldn't be shipped in the release tarball
   then..
  
  No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would
  not work anymore.
 
  Hrmpf.  Then can we just not delete it in make clean?
 
 I will think about this; but I still do not understand the problem
 there.

very easy to tell. You're talking about what configure builds, make
clean purges yet you're rolling the release tarball with a *.spec
already. Thus it's not configure building it, but autogen.sh at dist
stage. So the make clean shouldn't purge it, but going back into
mrproper mode should. Maybe someone can tell me if distclean is
supposed to clean this and doing a make clean would be the appropriate
fix here? (Not technically, but stylistic in general terms of
automake/autoconf etc.)

I know for now i use distclean to revert all built objects and
tempfiles into the release state and if clean is sufficient, then that
might be the answer to that question.

-- 
Best regards,
 Kilian


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] packaging review for new Debian packages

2004-12-29 Thread Kilian Krause
Hi Herbert,

Am Mittwoch, den 29.12.2004, 00:01 +0100 schrieb Herbert Poetzl:
 chkconfig --del network
  
   and it removes all the links from the various runlevels
   so that 'network' isn't started anymore ...
  
  The problem is that as soon as the next update to the network
  package happens it will re-enable the service.
  
  So you have to manually stop it and disable it (ugly, error prone,
  maintenance intensive) or write a hook for your packaging system to
  stop it (still ugly).
 
 wait you are saying that your distro re-enables
 disabled services when they get updated? sounds
 like a bug to me, I would not want a distro to
 decide which services I run, just consider the
 security impact, when I disable telnet and the
 distro decides to re-enable it 'just' because
 a new telnet package was available ...

well, it doesn't forcibly re-activate them. Just update-rc.d has a logic
that when *NONE* of the runlevels has any symlink for either
S??$SERVICENAME or K??$SERVICENAME then it'll try to create them for
it's thinking it's being installed for the first time. That does remove
overhead for a more special configuration of first and update install.
So the clean fix is to remove all but one symlink (which will be a K99
or so) to have this made working. 

In my idea the guest-vserver virtual package could/should provide as
many services as we need to be available, but not original daemons and
then offer a debconf dialog to the user querying about all the other
daemons to be shut off. Poking around /etc/rc*.d/[SK]* symlinks is valid
from debconf as far as i know the policy in case you do that upon user
request. Of course altering any symlinks except for our own without
asking or even telling the user is out of the limits we should be
staying within.

 I do not think that any serious distro will do 
 that ... so I guess it is 'safe' to disable those
 services right after guest installation ...

...which would be a nice task for a vserver-guest virtual package
including a fancy postinst script.

-- 
Best regards,
 Kilian


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] packaging review for new Debian packages

2004-12-29 Thread Enrico Scholz
[EMAIL PROTECTED] (Kilian Krause) writes:

  [ ... util-vserver.spec ...]
  Hrmpf.  Then can we just not delete it in make clean?
 
 I will think about this; but I still do not understand the problem
 there.

 very easy to tell. You're talking about what configure builds, make
 clean purges yet you're rolling the release tarball with a *.spec
 already. Thus it's not configure building it, but autogen.sh at dist
 stage. So the make clean shouldn't purge it, but going back into
 mrproper mode should.

Sorry, I am out of sync now... util-vserver has neither an 'autogen.sh'
script nor a 'mrproper' make-target.


The clearify things:

* 'util-vserver.spec' is *not* removed by 'make clean'
* 'util-vserver.spec' *is* removed by 'make distclean'; this clean rule
  is generated automatically by automake

* 'util-vserver.spec' *is* generated by './configure', './config.status'
  and (at least) 'make dist'
* 'util-vserver.spec' is *not* generated by automake, autoconf, aclocal,
  autoheader or libtoolize

And I still do not see the problem: it is common practice to build a
'.spec' file from a '.spec.in' file and to ship it in the tarball.
E.g. most Gnome packages have the behavior above; how is Debian
packaging done there?




Enrico
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] Vserver configuration for IPv4 and IPv6

2004-12-29 Thread Kilian Krause
Hi Herbert,

 please keep this discussion going (maybe some typical
 ipv6 examples or so?) so we can get a feeling for it.

what kind of typical example are you asking for? The default IPv6
address style is quite forward to the ipv4 notation (well, same logic
applies, but a slightly changed notation):

an ipv6 address would be:
2001:abcd:ef01::1/64
where the :: is an abbreviation for fill up with all 0 here.. Thus the
full length notation is:
2001:abcd:ef01:::::0001
which may be found with ipv6calc -i -m 2001:abcd:ef01::1.

The /64 is the prefix length which makes the local prefix be:
2001:abcd:ef01:

Length of IPv6 is 128bit in 8 blocks written in hex. Each of the blocks
is 2 bytes which makes an overall of 8*16=128 bit.

There's special target prefixes for site-local and link-local yet that
might be rather a routing question and transparent to the vserver, but
i'm not sure. 

Please ask for further hints if you need some.

-- 
Best regards,
 Kilian


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] Syslog and vserver

2004-12-29 Thread Liam Helmer
Further to this, here's the relevant bits from one of my syslog-ng
files. A word of note: the devices at /vservers/.devs/name/dev are
bind mounted into the vserver by another part of the startup... you
could change them safely to /vservsers/name/dev/log. This whole
configuration is generated with a script. You can ignore the mysql bits
if you're not doing this, naturally.

Cheers,
Liam



log { source(vservers) ; destination(vservers);
destination (console_9) ; };

source bind {unix-stream (/vservers/.devs/bind/log) ;} ;
source ldap {unix-stream (/vservers/.devs/ldap/log) ;} ;
source mysql {unix-stream (/vservers/.devs/mysql/log) ;} ;
source pdns {unix-stream (/vservers/.devs/pdns/log) ;} ;
source swivel {unix-stream (/vservers/.devs/swivel/log) ;} ;
source test {unix-stream (/vservers/.devs/test/log) ;} ;
source zmf {unix-stream (/vservers/.devs/zmf/log) ;} ;

destination mysql_bind {
pipe (/var/run/mysqld/mysql_bind.pipe
template(INSERT INTO logs
(host,vserver,facility,priority,level,tag,date,time,program,msg) VALUES
('$HOST','bind','$FACILITY','$PRIORITY','$LEVEL','$TAG','$YEAR-$MONTH-
$DAY','$HOUR:$MIN:$SEC','$PROGRAM','$MSG');\n) template-escape(yes));
} ;

log { source (bind); destination (mysql_bind) ; } ;

...
(repeated for each vserver)
...

log {   source (bind);
source (ldap);
source (mysql);
source (pdns);
source (swivel);
source (test);
source (zmf);
destination (vservers) ; destination (console_9) ; } ;

Cheers,
Liam

On Wed, 2004-12-29 at 01:58 +0100, Herbert Poetzl wrote:
 On Tue, Dec 28, 2004 at 07:19:50PM +0100, Oliver Welter wrote:
  Hi Folks,
  
  question on syslog
  
  What is the best way to use syslog inside the vServers - is it possible 
  to have one Logfile on the main maschine that collects all information ? 
 
 yes, definitely
 
  Whats the best way to do so ? 
 
 separate sockets for each vserver, combined
 by one syslog daemon (syslog-ng) is probably
 the best choice here ...
 
  Sharing a syslock socket ? 
 
 not a good idea, neither security nor performance
 wise ...
 
  Creating a syslog instance fpr each vServer and using 
  network-feature of syslog ?
 
 second best choice, almost as fast as sockets
 but might be more secure ...
 
  I am running Gentoo with syslog-ng if this matters
  
  THX
  
  Oliver
  -- 
  Diese Nachricht wurde digital unterschrieben
  oliwel's public key: http://www.oliwel.de/oliwel.crt
  Basiszertifikat: http://www.ldv.ei.tum.de/page72
 
 best,
 Herbert
 
  ___
  Vserver mailing list
  Vserver@list.linux-vserver.org
  http://list.linux-vserver.org/mailman/listinfo/vserver
 
 ___
 Vserver mailing list
 Vserver@list.linux-vserver.org
 http://list.linux-vserver.org/mailman/listinfo/vserver
 
-- 
Liam Helmer [EMAIL PROTECTED]

___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver