RFS: dudki - a process maintenance daemon
Dear mentors, I am looking for a sponsor to review and upload my package 'dudki'. dudki is a process maintenance daemon. Long description: Dudki! is a maintenance daemon that checks whether certain processes are running (based on pidfiles) and, if needed, tries to restart them. It supports a self-test commandline invocation which can be used in a cron job. . Homepage: http://kin.klever.net/dudki/ The package is lintian/linda clean. The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dudki/dudki_0.2.2-1.dsc I would be glad if someone uploaded this package for me. Regards. E. Bouthenot -- mail : [EMAIL PROTECTED] gpg : 0x414EC36E jid : [EMAIL PROTECTED] irc : kolter@(freenode|oftc) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ipw3945
On Sunday 12 November 2006 21:17, Loïc Minier wrote: On Sun, Nov 12, 2006, Daniel Baumann wrote: I don't want to have ipw* build with kernel-headers, but with iee80211 extra package. Argh! There are basically two reasons for this: 0. Currently the ieee80211 headers in mainline are recent enough to allow ipw* compiled against it. This may change again in future, hence I compile them all the time against ieee80211. 1. The ipw3945 package as it is now is anyway just a temporary package, because once it gets merged in mainline, the majority of users are going to use it there. After the merge into mainline, the ipw3945 is usefull for people which do want newer ipw* drivers with normal, non development kernels. From this time on, ieee80211 is required anyway. This is all *very* hypothetical. In fact, I believe the exact contrary: ieee80211 itself should be merged into the mainline, and ipw3945 will continue to build against linux-headers in all cases, and perhaps against ieee80211 by cheer luck. From what I understood, there are competing wireless stacks being merged into the mainline slowly, so would I be Intel, I would track the mainline. Both of your reasons certainly do not apply to etch, so perhaps these questions should be considered post-etch? It strikes me that you insist on depending on ieee80211 for hypothetical reasons when: 1) this package was removed from testing 2) the packaging is a mess, which makes it hard to e.g. support Xen-Vserver kernel headers 3) it works like a charm without! :-) Nobody has yet mentioned that ~11 other in-kernel modules are (as of 2.6.18) intimately related to the ieee80211 stack provided by the same linux source tree: airo atmel bcm43xx hostap ipw2100 ipw2200 orinico ray_cs wl3501 zd1201 zd1211rw Any user of a ipw3945 package that enforces the use of an entirely new ieee80211 stack also forfeits the opportunity to use those modules mentioned above. It is entirely feasible a user has both a ipw3945 mini-pci and a zd1211rw usb wlan that they would like to use at different times. Moreover, for people involved with custom debian distributions, it is not good for hardware support to have one fancy new module depending on an ieee80211 stack that renders 11 other wifi modules useless. Kel.
Why isn't this packages.d.o page updated?
Hi, the current version of the archivemail package in unstable is 0.7.0-1 (thanks Joeyh!), and it's correctly listed at http://packages.debian.org/archivemail, but http://packages.debian.org/unstable/mail/archivemail.html still shows the previous version 0.6.2-5. Why? The package now is in unstable for 3 days. Is this a bug somewhere? Thanks, Nikolaus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question: piuparts and mysql-server
I'm about to ask this list for a RFS for my package sitebar, which yesterday had an RC bug filed against it because of a dependency on mysql-client, which the bug filer had discovered by running piuparts on the package. I've since updated the package to include a Depends on mysql-client. After updating the package, I also ran piuparts on the package, and it kicks back an error that it cannot complete installation because if cannot find a mysql server. Here's the catch: I presently have mysql-server listed as a Recommends: because mysql can be run on another box other than the localhost. This seems to be the approach of many similar packages like drupal, diogenes. O.k. So if mysql-server is a Recommends:, then running piuparts will always fail. Is this just a limitation of piuparts? Thanks, Kevin -- Kevin Coyner GnuPG key: 1024D/8CE11941 signature.asc Description: Digital signature
Re: Question: piuparts and mysql-server
Hello Kevin, On Wed, 2006-11-15 at 16:06 -0500, Kevin Coyner wrote: Here's the catch: I presently have mysql-server listed as a Recommends: because mysql can be run on another box other than the localhost. This seems to be the approach of many similar packages like drupal, diogenes. O.k. Yes, this is correc. So if mysql-server is a Recommends:, then running piuparts will always fail. Is this just a limitation of piuparts? I wonder why your installation fails without a MySQL server available. I could go into details about the way you configure databases, but the following question seems more appropriate: why don't you use dbconfig-common as the way to configure your database? It concentrates code for packages wanting to configure databases into one place, making sure such issues as these are not solved again and again for every package. Thijs signature.asc Description: This is a digitally signed message part
Using the user nobody in my package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I am working with Daniel Baumann so my package can be uploaded to Debian. He has helped me really a lot, and I want to thanks him so much in here, publicly, for doing so. With him, I now understand a lot more about how debian packaging, and I did more progress than I could do in few years. But that's not the topic of this message. Me and some contributors have written DTC, a web control panel written in open source, designed from scratch since about 4 to 5 years now. Our goal is clearly to make very expensive commercial solutions like cPanel, Plesk and so on something of the past. See the project page here: http://www.gplhost.com/software-dtc.html For that system, we run in only one single UID/GID in the system: we use nobody:nogroup for all the hosted files. That includes: ftp access, mail system (delivered in user mailbox as nobody), and web. The control panel does the change of the User and Group directive in Apache so it doesn't use www-data anymore. The problem is that this breaks the policy in Debian, and that Daniel told me that this could not be acceptable for being uploaded to Unstable (it would be refused by FTP master). Daniel thought that I should ask in here what other think about it. Daniel suggested that there was the possibility of setting-up a specific user dtc that I could setup on my postinst script. But this leads to MANY problems that I will explain here. First, there is no way to guarantee that the UID will be always the same, and that's the main problem. 1/ Portability between servers If you have many servers using the control panel like we do (we run more than 100 servers using it ATM in production), and need to move files from one server to another, then the UID wont be the same. It would be really anoying to do chown all the time. 2/ Portability between systems With other operating systems running the same control panel, the 1/ might be even worth. 3/ Changing the defaults for all daemons Most daemons we use are running by default using nobody:nogroup, so it might be quite complicate to have it use another UID. 4/ All daemons have to use the same single UID/GID In our system, all hosted files are in /var/www/sites, using a single UID/GID. Meaning that with FTP, you can upload files for your web site, but as well see the messages for the mail. Also, generated files for all the daemons will be done under the UID/GID of Apache, so it can be generated by clicking on a button on the interface. Please post your thoughts here, so we can have a valuable chat on what to do. Thomas P.S: I'd love to have our panel upload for the next release of Etch, but more and more, it seems too late... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFW5dYl4M9yZjvmkkRAqYAAJ974DrO3NGOI7LzAhJKRgIt1ZsQUwCggxxa znH9bSnHZOPDtdhaymAxbAY= =5Sas -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
also sprach Thomas Goirand [EMAIL PROTECTED] [2006.11.15.2340 +0100]: For that system, we run in only one single UID/GID in the system: we use nobody:nogroup for all the hosted files. That includes: ftp access, mail system (delivered in user mailbox as nobody), and web. The control panel does the change of the User and Group directive in Apache so it doesn't use www-data anymore. Why nobody? Why don't you create your own user? Other daemons run as nobody and can hence access and manipulate files, potentially. Daniel suggested that there was the possibility of setting-up a specific user dtc that I could setup on my postinst script. But this leads to MANY problems that I will explain here. First, there is no way to guarantee that the UID will be always the same, and that's the main problem. Why do you care about the UID? I agree with Daniel, make a user dtc. If you have many servers using the control panel like we do (we run more than 100 servers using it ATM in production), and need to move files from one server to another, then the UID wont be the same. It would be really anoying to do chown all the time. rsync and others usually copy files by user name, not UID. For instance, you have to pass --numeric-ids to rsync to make it *not* do that. With other operating systems running the same control panel, the 1/ might be even worth. Don't ever assume you know the UID. Most daemons we use are running by default using nobody:nogroup, so it might be quite complicate to have it use another UID. Well, you'll have to. Sorry. I suggest you make it configurable this time by using a variable or #define setting. :_) Thanks for your work regardless; looks cool. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: Dream theater / Metropolis Pt 2: Scenes from a memory signature.asc Description: Digital signature (GPG/PGP)
Re: Using the user nobody in my package
Thomas Goirand [EMAIL PROTECTED] writes: Daniel suggested that there was the possibility of setting-up a specific user dtc that I could setup on my postinst script. But this leads to MANY problems that I will explain here. First, there is no way to guarantee that the UID will be always the same, and that's the main problem. 1/ Portability between servers If you have many servers using the control panel like we do (we run more than 100 servers using it ATM in production), and need to move files from one server to another, then the UID wont be the same. It would be really anoying to do chown all the time. Programs that copy files between servers should use the symbolic ownership rather than the UID/GID values. I believe that rsync, for instance, already does this. The issue here would only be if the servers were sharing a file system, in which case the administrator is going to need to create the user on a site-wide basis using a shared user store, such as LDAP. If they do that before installing the package, adduser won't create the user (as I understand it, at least). 3/ Changing the defaults for all daemons Most daemons we use are running by default using nobody:nogroup, so it might be quite complicate to have it use another UID. This isn't really a technical problem with the approach, just a coding issue with your package. I agree that it can be a fair bit of work to make sure that your package can run as a different user, but it's certainly possible. Note that I, for instance, would be very leery of your package as-is since the whole point of nobody/nogroup is that they don't own any files and have no access to anything. As soon as applications start using those accounts, those accounts are no longer unprivileged, which defeats their whole point. 4/ All daemons have to use the same single UID/GID The daemon should look up the UID and GID of its user at runtime, and then this shouldn't be a problem. In our system, all hosted files are in /var/www/sites, using a single UID/GID. Meaning that with FTP, you can upload files for your web site, but as well see the messages for the mail. Also, generated files for all the daemons will be done under the UID/GID of Apache, so it can be generated by clicking on a button on the interface. I'm not horribly thrilled by this either, actually, although I know it's a bit hard to avoid. Please post your thoughts here, so we can have a valuable chat on what to do. Well, modifying the Apache configuration in your package to run as a different user is right out. I agree that that would be a policy violation. Running all of your daemons as the same user that Apache runs as is a possibility. I don't really like that as a security model, but it's certainly better than using nobody/nogroup and modifying Apache to run as that user as well. Ideally, I would do something a bit more complex where the Apache code hands files off to a separate daemon running as a dedicated user for your package, which then audits what Apache is trying to do and then puts the files in an appropriate place with the correct ownership. Hope this was helpful! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
For that system, we run in only one single UID/GID in the system: we use nobody:nogroup for all the hosted files. That includes: ftp access, mail system (delivered in user mailbox as nobody), and web. The control panel does the change of the User and Group directive in Apache so it doesn't use www-data anymore. Editing other package's configuration files is proscribed by Policy, however such is the entire point of control-panel-like software, so I guess this isn't such a big issue. Daniel suggested that there was the possibility of setting-up a specific user dtc that I could setup on my postinst script. But this leads to MANY problems that I will explain here. First, there is no way to guarantee that the UID will be always the same, and that's the main problem. As others have said, most tools will transfer file ownership information by recording the user name, not the UID; however if this is not good enough (you want to use NFS, for example), Policy section 9.2.2 says that UIDs in the range 6-64999 are Globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only created on users' systems on demand. More at http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2. Of course, I guess you'd have to persuade whoever maintains the allocation list that you really do need a static UID assignment. :) -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: tunapie (updated package)
New version for new bug fixed upstream The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tunapie - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tunapie/tunapie_1.2.2-1.dsc Any takers? James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
Sam Morris [EMAIL PROTECTED] writes: For that system, we run in only one single UID/GID in the system: we use nobody:nogroup for all the hosted files. That includes: ftp access, mail system (delivered in user mailbox as nobody), and web. The control panel does the change of the User and Group directive in Apache so it doesn't use www-data anymore. Editing other package's configuration files is proscribed by Policy, however such is the entire point of control-panel-like software, so I guess this isn't such a big issue. I think you have to distinguish between control-panel software performing edits at the request of a user, in which case they're just a form of editor, and control-panel software modifying configuration files for its own purposes. The latter I think should still be forbidden. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
