Re: Retiring
Hi Mike, Am 27.04.2013 um 21:34 schrieb Mike Gabriel : > Hi Cajus, > > On Sa 27 Apr 2013 20:26:17 CEST Cajus Pollmeier wrote: > >> I've noticed that I cannot find as much time to work for Debian as I >> like to. Family and children need my time in the moment. I hope I'll be >> able to come back in the future some time. > > This is indeed sad news and understandable at the same time. Family keeps me > busy again and again, as well. > >> My packages have not yet been orphaned - I'm currently working on that. > > I on behalf of the Debian Edu packaging team will be happy to take over the > packaging of GOsa² and related packages. As GOsa² is a core component of the > Debian Edu main server, this seems like an obvious step. Anybody who feels > this call, too, is welcome to join in. > > Instead of orphaning, may I suggest that you announce in public > (debian-devel) that you hand over the packaging of all related GOsa² packages > to the Debian Edu Packaging Team? I will take over in a couple of weeks > (June/July) and upload a new packages set with the maintainer field updated. Yes, I'd be happy to pass packaging over to you. On the other side I'll continue to maintain the debian part of GOsa upstream, so maybe we find a mode of working that saves time on both sides. So I'll leave the gosa/goto packages the way they're now, waiting for you/Debian Edu to take over. > And about uif: I use that firewall script tool a lot and I will be happy to > take that one over, as well. Sure, I'll leave it in the state as the gosa ones ;-) Hopefully someone is interested in taking the qpid packages. Lets see. >> Thank you all for the fun and the good work you all do! >> Cajus > > Hope to meet you in person some time, hope there is some more cooperation on > GOsa upstream stuff here and there, as well. You're welcome and upstream is interested in helping Debian Edu / Debian to get their work done. Cheers, Cajus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8ddb60e4-02bb-44c3-90a7-f6408d919...@naasa.net
Autobuild and valgrind tests
Hi, I've uploaded a binary package[1] some days ago and found the powerpc build failing while processing the package tests[2]. Beeing no valgrind expert - what is the best way to deal with it? Just removing valgrind from the powerpc build dependencies should work, but how do I know if these are false positives? Thanks, Cajus --- [1] http://ftp.debian.org/debian/pool/main/q/qpid-cpp [2] https://buildd.debian.org/status/fetch.php?pkg=qpid-cpp&arch=powerpc&ver=0.12-1&stamp=1318087164 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2bbcbee57a7eba3ea8997b6589d2e...@ferdi.naasa.net
Re: Bug#402010: How to deal with #402010?
The problem is that these aspects are not packagable as some kind of "fire and forget" installation. I'd prefer the way Roland proposed, using some kind of # cat /etc/apache2/conf.d/gosa.conf Alias /gosa /usr/share/gosa/html include /etc/gosa/gosa.secrets # cat /etc/gosa/gosa.secrets RequestHeader set FooPassword very-secret-credentials The latter file can only be read by root, so the security "problem" is as critical as beeing able to read cleartext kerberos or sasldb passwords as root. This implementation only requires minimum changes and has no big overhead on the server side... Uh, and a "a2enmod headers" from postinst. Cheers, Cajus Am 05.04.2008 um 11:07 schrieb sean finney: hi, a few more ideas for you to think about: - create a user specific to the package, and 1: use a setuid wrapper binary for doing all ldap communications or 2: use some kind of user-restricted fastcgi type setup instead of standard apache mod_php/python/whatever or 3: run a seperate instance of $webserver listening on a different port (localhost:8080 or similar), and running as the specific user. you can then drop in a proxy config to make that available from the standard $webserver. sean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402010: How to deal with #402010?
Am Freitag, 4. April 2008 11:50:42 schrieb Holger Levsen: > Hi, > > On Friday 04 April 2008 09:18, Cajus Pollmeier wrote: > > to virtually any kind of web application accessing some kind of > > database/ldap passwords somewhere in the filesystem. > > I dont consider a web application which is used to configure the LDAP > database and FAI configuration (to install and configure all machines in > the network) just like any other web application. > > In this bug are several suggestions how to implement a way better mechanism > to deal with the password then the current one. If you read the comments, I'll see that it is not possible to use these suggestions. Besides maybe the last one, but there's no propper infrastructure in debian to use it directly. > Also I unarchived this bug, because I think the least you can and should do > is to document this in the README.Debian. (This=dont allow public html dirs > for users and leave safe mode on.) As said - I'm not responsible for the webserver setup of other people. Sure, I can put it inside the README and close this bug - waiting until the next one comes around and urges me to do something about it again. Ah wait, I can just orphan the gosa packages. > P.S.: regarding those four major ldap servers.. I think it would be a great > start if it would be more secure with one of them :-) You're welcome. Send patches. Cheers, Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to deal with #402010?
Hi, my position to this bug is written down in the bugtracker and I don't consider this a bug. Any opinions about what to do with it? It would apply to virtually any kind of web application accessing some kind of database/ldap passwords somewhere in the filesystem. This is a simulated problem - or maybe someone wants to implement built-in ACL support for (at least) the 4 major LDAP servers? Thanks, Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Am 30.01.2005 um 16:01 schrieb Thiemo Seufer: Cajus Pollmeier wrote: Hi, I'm looking for a script that regenerates Packages* and Release files for a complete mirror. Due to some installer development, I currently need to switch the mirrors during installation in order to get up to date packages. Tried to work around this with a simple script that merges my packages into the local mirror and regenerates everything as needed. But sadly this doesn't seem to be perfect :-( The installer just doesn't want to get some of these packages, even if the md5's are correct. Switching from http to ftp gets some more of them and stucks some packages later. Grrr. You might want to compare your script with the one for partial d-i test mirrors, available from d-i SVN in trunk/scripts/testmirror. Here's the result of some testing: debpool:is fine for new pools, but recreating the whole mirror with .deb and .udeb packages didn't work and I'm not the perl guy who's capable of fixing it. dak:too complicated for fire and forget mirrorer: not tested because alioth is still down departialmirror: not a package, after resolving some dependencies, it actually did not do what I wanted. Finally I fixed the quick'n dirty bash script. It lacks features like gpg signing, SHA entries in Releases, etc., but for a local test mirror its failrly enough ;-) If someone's interested, I can clean it up an put it somewhere. Thanks for your hints! Cheers, Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Am 30.01.2005 um 16:29 schrieb Marc Haber: On Sun, 30 Jan 2005 14:54:16 +0100, Cajus Pollmeier <[EMAIL PROTECTED]> wrote: I'm looking for a script that regenerates Packages* and Release files for a complete mirror. Due to some installer development, I currently need to switch the mirrors during installation in order to get up to date packages. Have a look at the debpool package. Ah. Will do. Seems to be in experimental and the description is matching ;-) Thanks, Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Am 30.01.2005 um 15:44 schrieb Aurelien Labrosse: Cajus Pollmeier a écrit : Hi, I'm looking for a script that regenerates Packages* and Release files for a complete mirror. Due to some installer development, I currently need to switch the mirrors during installation in order to get up to date packages. Tried to work around this with a simple script that merges my packages into the local mirror and regenerates everything as needed. But sadly this doesn't seem to be perfect :-( The installer just doesn't want to get some of these packages, even if the md5's are correct. Switching from http to ftp gets some more of them and stucks some packages later. Grrr. So let's try this way: Is there a ready to use script which I didn't find by googling around yet? Thanks, Cajus Hi Cajus, Do you use 'dpkg-scanpackages' ? It rebuild Packages file for directories that contains..pakages. Hi Aurelien, sure, I'm using dpkg-scanpackages. But there are some problems I couldn'r resolve yet. Cheers, Cajus
Debian mirror scripts
Hi, I'm looking for a script that regenerates Packages* and Release files for a complete mirror. Due to some installer development, I currently need to switch the mirrors during installation in order to get up to date packages. Tried to work around this with a simple script that merges my packages into the local mirror and regenerates everything as needed. But sadly this doesn't seem to be perfect :-( The installer just doesn't want to get some of these packages, even if the md5's are correct. Switching from http to ftp gets some more of them and stucks some packages later. Grrr. So let's try this way: Is there a ready to use script which I didn't find by googling around yet? Thanks, Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian installer and non-official drivers
Am Donnerstag, 28. Oktober 2004 10:38 schrieb Joey Hess: > Cajus Pollmeier wrote: > > Just one question. Lets say I'd put some extra driver modules for > > hardware not officially supported by the debian installer on a floppy > > disk (in form of an a .udeb) and let the installer load this file during > > the installation in order to detect the additional hardware. > > > > Would this udeb get installed into my target system later on? If this > > additional driver is needed for i.e. disk access, it should be placed in > > the initrd when the target kernel gets installed. > > It would not. You can however include a udeb on your floppy that > installs a prebaseconfig hook script which would run after the base > system is installed, or a base-installer hook script which would run > just before base is installed (or perhaps both), and at that point do > one of these things, in approximate order of difficulty and inverse > order of cleanliness and desirability: > > a. copy the module into /target from the d-i system > b. install a .deb of the module into /target from the floppy > c. add something to sources.list for the apt repository you should have > that contains the .deb, and then use apt-install to get it installed Ok. Will try (b) to use the apoximated intersection between cleanliness and difficulty ;-) Cheers, Cajus PS: Sorry for mailing multiple times, but it took about three hours to see the mail coming up in the list.
Debian installer and non-official drivers
Hiho! Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. Any comments? Greetings, Cajus
Debian installer and non-official drivers
Hiho! Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. Any comments? Greetings, Cajus
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Freitag, 1. August 2003 15:31, David Z Maze wrote:
> Cajus Pollmeier <[EMAIL PROTECTED]> writes:
> > On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
> >> Severity: serious
> >> Justification: Policy 9.1.1
>
> ("Debian should obey the FHS"; I don't claim to be an FHS expert, but
> all it seems to say about /etc is "no binaries", which this doesn't
> violate.)
>
> >> The shell script /etc/acpi/powerbtn.sh should be installed in something
> >> else, like /usr/share/acpid/ or /usr/sbin/.
> >
> > I've no problem with that, but:
> >
> > These scripts used by acpid should be treated as some kind of user
> > configuration, like i.e. cron keeps skripts installed by someone in
> > /etc/cron.daily, acpid keeps skripts that take actions when some
> > events happened.
>
> Is this "script that gets run when the console user presses the power
> button", and is it obvious that the user could potentially want to
> configure it? If so, then it makes sense that it should be a
> configuration file, and so by policy 10.7.2 it should live in /etc.
> (And as you point out, it's not like there aren't other admin-editable
> scripts in /etc already, say, all of /etc/init.d.) My reading is that
> what you're doing now is fine and the bug is wrong.
So in case of a "power down" script, this may be somewhat fixed in its
task. This would be true. But this script must not be the only one. Maybe
the user wants to place a script for i.e. closing the LID or do special
reactions on suspend events etc.
In my understanding /etc/acpid is the correct place for that. So, I changed
the serevity of the bug. I'm just off to vacations tomorrow - will look into
this
when I'm back.
Thanks,
Cajus
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote: > Package: acpid > Version: N/A; reported 2003-07-31 > Severity: serious > Justification: Policy 9.1.1 > > The shell script /etc/acpi/powerbtn.sh should be installed in something > else, like /usr/share/acpid/ or /usr/sbin/. > > -- System Information > Debian Release: 3.0 > Architecture: i386 > Kernel: Linux imperatrice.arcanes 2.4.18-686 #1 Sun Apr 14 11:32:47 EST > 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] I've no problem with that, but: These scripts used by acpid should be treated as some kind of user configuration, like i.e. cron keeps skripts installed by someone in /etc/cron.daily, acpid keeps skripts that take actions when some events happened. I've no idea about the exact handling of this issue. Should I move these scripts to /usr/share/acpid or /usr/sbin? Thanks for any hints, Cajus
Bug#171270: ITP: ulog -- xsession equivalent of commands such as who or last
Package: wnpp Version: unavailable; reported 2002-11-30 Severity: wishlist * Package name: ulog Version : 0.3.0 Upstream Author : Hervé Eychenne <[EMAIL PROTECTED]> * URL : http://www.ulog.org * License : GPL Description : xsession equivalent of commands such as who or last Ulog enables you to find currently opened X sessions. It is the X equivalent of commands such as who or last. A ulogd daemon records the start and the end of X sessions. Then it is possible to know which users are currently logged in, according to several search criteria. New logins/logouts can also be notified instantaneously by the server in real-time mode. Mainly this program is ideal for real big enviroments with hundreds of X users, several terminal servers / workstations. The administrator can easily track down the user to a machine in order to support them, make statistics etc. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dell 2.4.20-rc1 #1 Wed Nov 27 20:30:52 CET 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)
Bug#170565: ITP: uif -- Advanced iptables-firewall script
Package: wnpp Version: unavailable; reported 2002-11-24 Severity: wishlist * Package name: uif Version : 1.0.4 Upstream Author : Joerg Platte <[EMAIL PROTECTED]> * URL : http://area51.mfh-iserlohn.de/uif * License : GPL Description : Advanced iptables-firewall script Complete package to create and simplify iptables packetfilter rules using perl. It was developed for a diskless router system that can store its configurations in regular files or ldap databases. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dell 2.4.20-rc1 #1 Sat Nov 9 14:28:56 CET 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)
Bug#170546: ITP: gnarwl -- Email autoresponder based on LDAP
Package: wnpp Version: unavailable; reported 2002-11-24 Severity: wishlist * Package name: gnarwl Version : 2.3 Upstream Author : Patrick Ahlbrecht <[EMAIL PROTECTED]> * URL : http://www.oss.billiton.de * License : GPL Description : Email autoresponder based on LDAP Gnu Neat Auto Reply With LDAP Gnarwl is an email autoresponder. Unlike the original vacation(1) program, gnarwl is based on LDAP. Traditionally you had to give every user, who wanted to use autoreply facilities full fledged system accounts (trusting them to set their forwarding up properly, cursing when they didn't). With gnarwl this is history. User information is now stored in LDAP. Thats right, no more messing around with system accounts or homedirs for users who just want their email working, but don't care to fuss around with shell commands. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dell 2.4.20-rc1 #1 Sat Nov 9 14:28:56 CET 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)
Re: kbiff.mo should be removed from kde-i18n-*
Am Montag, 22. April 2002 09:18 schrieb Jean-Michel Kelbert: > Hi, > > I made a package from kbiff : a mail notification utility. > The source code include locales files : kbiff.mo > However this file is also in kde-i18n-*. Then when I tried to installed > the package I made, dpkg stop because it tried to overwrite kbiff.mo > > >from kde-i18n-fr. > > I asked the upstream author to know why he provide this files, here is > his answer : > > "The file in kde-i18n is old. KBiff *used* to be included in kdenetwork > a long time ago and there was some translations in kde-i18n as a result. > When I removed KBiff from kdenetwork, those .mo files were never > removed." > > So to my mind kbiff.mo should be removed from kde-i18n-* package, isn't > it ? There's a bug assigned to this issue on bugs.kde.org #39379. Since they degraded it to "wishlist", I guess it should be fixed in debian kde-i18n before they act? Greetings, -Cajus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
