Re: cryptdisks(-early) initscripts, dependencies and loops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Jonas Meurer wrote: > the problem is that loads of possible setups are possible, all > introducing different required initscript order. either another > initscript needs to be invoked before, or after, or between the > cryptdisks-early and cryptdisks initscripts. What we have here is a dependency tree of arbitrary height, with each node requiring an invocation of cryptsetup, lvm, mdadm, nbd or pretty much anything else. So it's clear that you can never cover all possibilites with a finite number of init scripts that run in a sequence. An event-based system might be able handle this, but only if it allows the same script to be invoked multiple times, taking different actions each time. Perhaps we need a little script that walks the dependency tree, and just calls the necessary helper script for each node in turn. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwItRYACgkQXjXn6TzcAQnjoACbBXIU2d8ZJ/VeXj/5p+M1t8Uy hLIAnRzCMC587mrKfRvmLwwepe6hL6zq =P0c4 -END PGP SIGNATURE- -- 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/huaceo$h6...@dough.gmane.org
Re: finally: packages to optionally create default collaboration dirs
On Thu, Jun 03, 2010 at 10:36:09AM +0200, C. Gatzemeier wrote: > Am Thu, 3 Jun 2010 00:43:20 +0400 > schrieb Stanislav Maslovski : > > > > The great thing about Debian is that it can mean and handle so many > > > different things for so many people. > > > > Yes, that is why we should not limit it to a fixed number of > > predefined choices. > > Configurable defaults should implement full choice, unlike missing > functionality. Well, and how does _your_ proposal implement _full_ choice? > One can miss some configuration options about the optional setup of > collaboration directories (think $HOMEs for groups), but sorry, Debian's > mirriads of functionalities or packages that one can perfectly keep > disabled (or not installed) can hardly be unacceptable. Simply missing those "optional options" that are intended to be disabled or not installed can also hardly be unacceptable. But well, if you want to spend your time on this, it is up to you, of course. Just make it sure that it will not show up in places where it should not (like in debian installer). -- Stanislav -- 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/20100604082156.ga25...@kaiba.homelan
Re: cryptdisks(-early) initscripts, dependencies and loops
Am Fri, 4 Jun 2010 02:49:32 +0200 schrieb Petter Reinholdtsen : > It is possible event baset boot sequencing might make it easier to > change the ordering, but also there the maintainer of a package need > to decide on some ordering. The defined order in /etc/init/cryptdisks-udev.conf is simply "start on block-device-added ID_FS_USAGE=crypto". The boot sequence then automatically corresponds to how things have been installed on top of each other. You'd have to check if upstart is ready for use in initramfs. Cheers, Christian -- 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/20100604105516.1fd62...@smtp.tu-bs.de
Re: cryptdisks(-early) initscripts, dependencies and loops
[C. Gatzemeier] > Am Fri, 4 Jun 2010 02:49:32 +0200 > schrieb Petter Reinholdtsen : > >> It is possible event baset boot sequencing might make it easier to >> change the ordering, but also there the maintainer of a package need >> to decide on some ordering. > > The defined order in /etc/init/cryptdisks-udev.conf is simply "start on > block-device-added ID_FS_USAGE=crypto". > > The boot sequence then automatically corresponds to how things have been > installed on top of each other. You'd have to check if upstart is ready > for use in initramfs. Good to see. I suspect this was possible, but had not verified it. This is a great example of the issues a event based boot system will solve, which the current sequence based boot system do not. Other examples are failure to fsck and mount USB disks during boot (fatal if the home directory is on that disk :) and services failing because the network is not available when the service start during boot. There are several such issues with the current boot system. We need to address this fundamental problem with the current boot system, but I believe we are too late in the Squeeze release cycle to fix it before Squeeze. A good start you all could help out with, is to move as many init.d scripts as possible out of rcS.d/. If the script do not _have_ to run before single user mode is entered, it should not be started from rcS.d/. Eventually we can move network initialization out of rcS.d/ too. Below is the list from http://lintian.debian.org/~pere/test-20100603.log> of all scripts started after mountall-bootclean.sh. At least some of these should be moved from rcS.d/ to rc[2-5].d/. To do this without breaking existing installations, we need to start at the end and move scripts one by one, while making sure package upgrades update all depending packages first. Lucikly a lot of these scripts are standalone (like buildd) and can be moved without much coordination. :) S20bootcdram S20mountoverflowtmp S21adjtimex S21atm S21bootcdflop S21ebtables S21fsprotect S21iptables-persistent S21mountdebugfs S21mt-st S21netenv S21pcmciautils S21pppd-dns S21procps S21pyroman S21rdnssd S21resolvconf S21udev-mtab S21ufw S21x11-common S21zvbi S22ifupdown S23ifscheme S23networking S24aoetools S24bastille-firewall S24cman S24nbd-client S24portmap S24rpcbind S25gfs-tools S25gfs2-tools S25nfs-common S25rgmanager S26mountnfs.sh S27mountnfs-bootclean.sh S28console-screen.sh S29kbd S30console-setup S31alsa-utils S31arno-iptables-firewall S31bootmisc.sh S31clvm S31console-cyrillic S31corosync S31cryptmount-early S31dns-clean S31eeepc-acpi-scripts S31espeakup S31ferm S31fiaif S31fuse S31gom S31guarddog S31guidedog S31later-readahead S31libpam-devperm S31libpam-foreground S31lm-sensors S31mini-buildd-bld S31netperf S31nviboot S31open-iscsi S31oss4-base S31quota S31racoon S31schroot S31screen-cleanup S31selinux-basics S31setkey S31setserial S31shorewall S31shorewall-lite S31shorewall6 S31shorewall6-lite S31srptools-boot S31svgalib-bin S31switchconf S31tmux-cleanup S31uptimed.sh S31urandom S32buildd S32zfs-fuse S33stop-bootlogd-single I do not know which one of these can be moved. There are a lot of them, and each will have to be evaluated individually. :) Moving scripts out of rcS.d/ will get us one step closer to a useful and working single user, increase concurrency during boot (speed up the boot) and make it easier to move to an event based boot sequencing (the remaining pieces in rcS.d/ can be converted to event scripts one at the time, starting at the first script). Happy hacking, -- Petter Reinholdtsen -- 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/2flsk53yw98@login1.uio.no
Re: finally: packages to optionally create default collaboration dirs
Am Fri, 4 Jun 2010 12:21:56 +0400 schrieb Stanislav Maslovski: > Well, and how does _your_ proposal implement _full_ choice? IMHO we are at a place to suggest constructive answers and enhancements to proposals. Everybody lives happily with things they don't need nor are affected by. Regards, Christian -- 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/20100604123844.0558b...@smtp.tu-bs.de
Bug#584536: ITP: libmoosex-setonce-perl -- write-once, read-many attributes for Moose
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libmoosex-setonce-perl Version : 0.100471 Upstream Author : Ricardo SIGNES * URL : http://search.cpan.org/dist/MooseX-SetOnce/ * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl Description : write-once, read-many attributes for Moose The SetOnce attribute lets your class have attributes that are not lazy and not set, but that cannot be altered once set. . The logic is very simple: if you try to alter the value of an attribute with the SetOnce trait, either by accessor or writer, and the attribute has a value, it will throw an exception. . If the attribute has a clearer, you may clear the attribute and set it again. This module is required by a new upstream release of libdist-zilla-perl. -- 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/20100604122058.10350.19471.report...@marvin.43-1.org
Re: cryptdisks(-early) initscripts, dependencies and loops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Gatzemeier wrote: > The defined order in /etc/init/cryptdisks-udev.conf is simply "start on > block-device-added ID_FS_USAGE=crypto". Good, how does the next step work? For example, after cryptsetup ran, we found an LVM volume and must now run lvm. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwI+t0ACgkQXjXn6TzcAQlwZgCgvVmZzEx6+wRUdv3WR4b3nO7X MYEAoKzkmLhF7Hti5g6fOPHWi/9N2ioc =iTKE -END PGP SIGNATURE- -- 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/huatsv$d7...@dough.gmane.org
Bug#584543: ITP: qxmlrpc -- full Qt4 based implementation of XML-RPC protocol.
Package: wnpp Severity: wishlist Owner: Alexander Gerasiov * Package name: qxmlrpc Version : svn6 Upstream Author : Dmytro Poplavskiy * URL : http://code.google.com/p/qxmlrpc * License : LGPL-2.1 Programming Lang: C++ Description : full Qt4 based implementation of XML-RPC protocol. It provides an easy way to construct, send and receive XML-RPC messages on the client side, and process XML-RPC messages on the server side. QXML-RPC licensed under LGPL. I use this library in some projects and suppose it could be useful to have it in the repository. -- 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/20100604132711.31125.88796.report...@vice.lan
Re: pid file security
apologies for butting-in without being able to continue the thread, but i've just seen this: http://advogato.org/person/etbe/diary/779.html which links to this: http://lists.debian.org/debian-devel/2010/05/msg00067.html can i please gently remind people that depinit solved the security and fork-bombing issues years ago. i do keep mentioning depinit, on debian lists, but there is typically absolutely zero response, which i do not understand. nevertheless, as a debian and free software advocate i feel compelled to keep pointing people at solutions: it's up to you to investigate them. depinit solved the fork-bombing issue because richard lightman was concerned about attacks on his internet-facing system. richard added code which actively tracks child signals (depinit is highly unusual and innovative in that it catches ALL signals, and can therefore react _to_ any signal) and analyses the timing etc. and provides a means to trigger arbitrary "scripts" based on the signal type. i recall a discussion with richard back in 2004/5 where he said that when depinit is asked to stop a dependency/service, it does so by first sending "graceful" signals, then goes on to take increasingly aggressive action, including deciding, based on child-fork-bombing, that a service has been corrupted and thus needs to be terminated with extreme prejudice. richard also solved the security PID problem ... by doing away with the need for the PID file. in other words, a service is _always_ run in "foreground" mode. if it dies (i.e. a segfault signal is caught), the service is restarted automatically - by depinit (based on the signal alone). thus, the need for safe_mysql goes away entirely; the need for "apache2ctl start" goes away (i.e. you use apache2 -c FOREGROUND=True or whatever it is) and so on. in this way, there simply _is_ no need for a PID file, period. the relevant state information is contained within depinit itself, and you can guarantee that depinit will catch the signal. one additional incredibly useful action of this "foregrounding" approach to services was that he added the means to connect dependent services via pipes, between their stdin and stdout. the advantage of the entire services approach that richard took in depinit is phenomenal: richard created dependent services where in real-time you could script sshd's stdout (logging output) into _another_ service, which was a shell-script that analysed the contents and looked for "unauthorised login" attempts. more than three of those occurring within a specified time, and iptables would be called to block that user's IP address. voila: no delays due to syslog polling: instant and real-time attacker blocking, all using simple shell scripts. [the alternative - continuous polling and reading of syslog entries - is just utterly messy, results in potential delays, and requires that each and every "polling" program written for a particular service understand the concept of syslog, how to read it, how to read the last entries etc. etc. just... messy.] so i feel compelled to point these things out, along with the other incredible benefits that depinit brings including _massive_ reductions in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was doing about 90 at the time), and phenomenal near-unbelievable improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when debian was doing about 60 at the time), as it pains me to see depinit being totally ignored and these security and painful issues being discussed _years_ after a solution has already been done, and proven to be effective. you are welcome to contact me and discuss this further, if i can remember any of the details i will be glad to describe them, and if necessary go dig out the depinit scripts that i created for a KDE debian desktop system, 4 years ago. which included solving the udevsettle massive delay problems, by parallelising them and working out the dependencies for critical startup services. l. -- 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/aanlktimphzloqs1kfvzin2_er_z2qffhihhvnpq36...@mail.gmail.com
Waiting for SCons 2.0: rebuild test
Hello, SCons developers are close to release new major release of SCons, which started to deprecate some obsolete function and dropped support for Python code older than 2.4. Full release notes can be found here: http://sourceforge.net/projects/scons/files/scons/2.0.0.beta.20100531/RELEASE.txt/view SCons unittest is very well designed, and there should not be any major breakages, but risk of backward incompatible changes could affect some Debian packages which does not see updates from upstreams so often. So, I rebuilt reverse dependencies of SCons to spot some problems, and I published my results online. Here is a brief summary: * 58 packages build-depending on SCons * 53 packages built successfully (2 of them needed sourceful changes, such as build-dependency mangling or so, but not related to SCons). * 4 packages FTBFS: * 1 package has temporary dependency screwup This is a dd-list of FTBFSing packages: Tim Abbott sagemath Michael Ablassmeier kstreamripper William J Beksi skim (U) Zhengpeng Hou skim (U) Steffen Joeris abakus skim maintainers skim Jaldhar H. Vyas skim (U) Build logs and other details can be found here: http://people.debian.org/~dktrkranz/scons-2.0 I have already informed upstream of my rebuild tests, and I hopefully will be given instructions on how to properly fix FTBFSes, which I will report as important bugs against affected packages. SCons 2.0 release should happen in June, if RT does not mind, I intend to upload 2.0 to unstable shortafter. Thoughts? -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Bug#584553: ITP: shr-specs -- SHR DBus XML specification & documentation
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: shr-specs Version : 0.1+git20100511 Upstream Author : Klaus Kurzmann * URL : http://www.shr-project.org/ * License : CC-BY-SA Programming Lang: XML Description : SHR DBus XML specification & documentation The Desktop-Bus prepares applications to communicate with another by the sending of predefined signals. The process is agnostic about programming languages, but the collaborating tools need to agree on a common set of signals and their interpretation. This package provides the DBus specifications of the SHR software stack, which sits on top of the freesmartphone.org software stack. Process these with a dbus binding generator to create stubs for your program. -- 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/20100604141656.11163.40823.report...@earth.universe
Bug#584555: ITP: pdfminer -- PDF parser and analyzer
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: pdfminer Version : 20100424 Upstream Author : Yusuke Shinyama * URL : http://www.unixuser.org/~euske/python/pdfminer/ * License : MIT Programming Lang: Python Description : PDF parser and analyzer PDFMiner is a tool for extracting information from PDF documents. Unlike other PDF-related tools, it focuses entirely on getting and analyzing text data. PDFMiner allows to obtain the exact location of texts in a page, as well as other information such as fonts or lines. It includes a PDF converter that can transform PDF files into other text formats (such as HTML). It has an extensible PDF parser that can be used for other purposes instead of text analysis. -- Jakub Wilk signature.asc Description: Digital signature
Can not mount samba with this option "credentials"
I can not mount the samba server with this option "credentials" a few days ago. It can work before, and if i use options "user=myname" and type the password, it still can work. My system is amd64/sid, uname -a: Linux redcat 2.6.32-5-amd64 #1 SMP Tue Jun 1 04:34:03 UTC 2010 x86_64 GNU/Linux my credentials file have 3 line like this: username=myname password=mypassword workgroup=MYWORKGROUP my fstab like this: //sambaserver/share /samba cifs iocharset=utf8,credentials=/etc/smbmount.conf 0 0 dpkg -l | egrep -i '(smb|samba)' ii libsmbclient 2:3.4.8~dfsg-1 shared library for communication with SMB/CIFS servers ii libwbclient0 2:3.4.8~dfsg-1 Samba winbind client library ii samba-common 2:3.4.8~dfsg-1 common files used by both the Samba server and client ii samba-common-bin 2:3.4.8~dfsg-1 common files used by both the Samba server and client ii smbfs 2:4.5-1 Common Internet File System utilities - compatibility package ii winbind 2:3.4.8~dfsg-1 Samba nameservice integration server Please help, and thank you. -- 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/4c090276.8050...@wonghome.net
Re: Waiting for SCons 2.0: rebuild test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/10 10:30, Luca Falavigna wrote: > Hello, > > SCons developers are close to release new major release of SCons, which > started to deprecate some obsolete function and dropped support for > Python code older than 2.4. Full release notes can be found here: > http://sourceforge.net/projects/scons/files/scons/2.0.0.beta.20100531/RELEASE.txt/view Does SCons finally support SONAMES or do we still have to manually do that? I don't see any reference to that in the release text. - -- Saludos, Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMCTQPAAoJEKO6uuJAjdbPHE0QAJG6GivBUNfxO8vwD+tNdaL9 /Zeg3G7vaY0Zt4QsF7HP/eQgTEs8e4ZXcqm/OIpPIp4axoRH1gA20u8N+bltGu3t H2wW56VjFQhg7rkYPwjmpEzcC0m9ElT/p2FdNG4A0fp15RACXycXtcAd9GeXXpVP YqonYqP76ADDwZ07Pq4W84nUkXYfufbflKvPDLqh80WIGz+o1epI8OYWRcoz+ahI BbJiDHYVXaqp9ke3pwJVj0Mi88UJ48ot0Lpiftr5b1VQ5vVYxHRqnEXX2CfIzvCU TShh9kuaaSnclE7Z801XPy/wwMKK5vh8boe6l/AJiV3CstWiCin42g9dHWp05QXA s9jq/4VOCnue2BDxZGFEIY7R42VClVFrVYQgO8OKeL+fJMwd9doKWLMlAHvFUbFI YpuQfnfCPhx9FN5MwVo2MGVmN5Up/s11LsGtxi60Gqmyi/HECG0MQ889JGg8w3or BLG6yNslckPNldxlvTmu/CV0BAZB1b0JYE6/WpDe/VK1IGuhPIFMTPvccG3L+VJU XCRegHov8DaCHwECUka1Ov74u83cqVB3awSVQreP28LW43AXacwhsWIuaX+/FLR7 RS+qVRYipf8pvvt0eSS6/0G3P9Wekq7okwbr5P5OX6EhqQ8Vh2lMWtPt92d78B/c x3emlyjtjKzcA7UbyHyy =22T4 -END PGP SIGNATURE- -- 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/hubc6k$3v...@dough.gmane.org
Bug#584570: ITP: portabase -- An easy-to-use personal database application
Package: wnpp Severity: wishlist Owner: Jeremy Bowman * Package name: portabase Version : 2.0 Upstream Author : Jeremy Bowman * URL : http://portabase.sourceforge.net/ * License : GPL Programming Lang: C++ Description : An easy-to-use personal database application PortaBase is a program for conveniently managing one-table database files. It is available for many platforms, including Linux, Mac OS X, Windows, and Maemo. Features include: * String, Integer, Decimal, Boolean, Note (multi-line text), Date, Time, Calculation, Sequence, Image, and Enum column types; * custom data views (subsets of the columns in any order); * filter the displayed rows using sets of conditions; * sort the rows by any combination of columns, each in ascending or descending order; * add, delete, rearrange, and rename columns at any time; * view summary statistics for columns (total, average, min, max, etc.); * import data from CSV, XML, and MobileDB files; * export data to CSV and XML files; * command-line format conversions (to and from XML, from MobileDB); * optional data file encryption. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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/20100604084634.3090.60696.report...@debianvm.comcast.net
Re: Waiting for SCons 2.0: rebuild test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il giorno Fri, 04 Jun 2010 13:12:52 -0400 Felipe Sateler ha scritto: > Does SCons finally support SONAMES or do we still have to manually do > that? I don't see any reference to that in the release text. I don't think so. I remember I've seen a request on Tigris tracker, but I can't remember its # right now. - -- .''`. : :' : Luca Falavigna `. `' `- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwJO4YACgkQnXjXEYa8KlC4eACfY57+uBGmmhkOGIaDBn3zUSuh Ws4An3SaDenP8C14mgwhlEL+RWgS4Qq4 =NPqn -END PGP SIGNATURE-
Re: Can not mount samba with this option "credentials"
Quoting John Wong (jo...@wonghome.net): > I can not mount the samba server with this option "credentials" a few > days ago. > It can work before, and if i use options "user=myname" and type the > password, it still can work. .../... > dpkg -l | egrep -i '(smb|samba)' The involved package is cifs-utils. You probably have cifs-utils 4.5-1 and are hit bug bug #584104. signature.asc Description: Digital signature
Re: Waiting for SCons 2.0: rebuild test
Hi, On Fri, 2010-06-04 at 16:30 +0200, Luca Falavigna wrote: > So, I rebuilt reverse dependencies of SCons to spot some problems, and I > published my results online. Here is a brief summary: > > * 58 packages build-depending on SCons > * 53 packages built successfully (2 of them needed sourceful changes, > such as build-dependency mangling or so, but not related to SCons). > * 4 packages FTBFS: > * 1 package has temporary dependency screwup What specifically does "temporary dependency screwup" mean? > I have already informed upstream of my rebuild tests, and I hopefully > will be given instructions on how to properly fix FTBFSes, which I will > report as important bugs against affected packages. SCons 2.0 release > should happen in June, if RT does not mind, I intend to upload 2.0 to > unstable shortafter. I'm assuming that this is "just" a new upstream version? i.e. once the FTBFS packages are fixed and assuming no RC issues in scons itself appear, there'd be no need for any explicit action from the Release Team and SCons 2.0 would simply transition to testing once its 10 days were up? Regards, Adam -- 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/1275676646.30695.537.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#584579: ITP: wikkid -- Bazaar-backed wiki implementation
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: wikkid Version : 0.1 Upstream Author : Tim Penhey * URL : http://launchpad.net/wikkid * License : AGPL Programming Lang: Python Description : Bazaar-backed wiki implementation A wiki that is backed by Bazaar that allows local branching of the wiki for later merging. It doesn't have any page locks and uses Bazaar's three way merging. -- 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/20100604184311.7315.91015.report...@ganieda.vernstok.nl
Re: cryptdisks(-early) initscripts, dependencies and loops
On Fri, Jun 04, 2010 at 03:08:45PM +0200, Marcus Better wrote: > C. Gatzemeier wrote: > > The defined order in /etc/init/cryptdisks-udev.conf is simply "start on > > block-device-added ID_FS_USAGE=crypto". > Good, how does the next step work? For example, after cryptsetup ran, we > found an LVM volume and must now run lvm. That's the easy part: a udev rule that calls vgscan (/lib/udev/rules.d/85-lvm2.rules, on Ubuntu). The hard part is getting cryptsetup itself to work in an event-driven manner. Ubuntu 10.04 has this mostly right, but there are still unsolved bugs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100604191820.ga29...@dario.dodds.net
Re: Bug#584579: ITP: wikkid -- Bazaar-backed wiki implementation
On Fri, Jun 04, 2010 at 08:43:18PM +0200, Jelmer Vernooij wrote: > * Package name: wikkid > > A wiki that is backed by Bazaar that allows local branching of the wiki > for later merging. It doesn't have any page locks and uses Bazaar's three > way merging. Sounds like ikiwiki. If there is a significant overlap in the features of both projects, perhaps you should inform the upstream maintainers so they can work together? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: cryptdisks(-early) initscripts, dependencies and loops
Hi. I guess it will take some time until Debian has switched to some event-driven init-system, right? Especially as there seem to be multiple systems for this ;) On Fri, 2010-06-04 at 02:49 +0200, Petter Reinholdtsen wrote: > Those wanting another ordering can edit the init.d scripts directly to > declare some other ordering or provide override headers in > /etc/inssserv/overrides/ if they want to avoid editing in the > conffiles included in the package. So if there's an easy way to override the dependencies,... wouldn't it be possible that cryptsetup provides some debconf/etc mechanism to select to determine the order of things like lvm/raid/nbd/dm-crypt/etc ? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Waiting for SCons 2.0: rebuild test
Il giorno Fri, 04 Jun 2010 19:37:26 +0100 "Adam D. Barratt" ha scritto: > > * 1 package has temporary dependency screwup > What specifically does "temporary dependency screwup" mean? http://people.debian.org/~dktrkranz/scons-2.0/depwait/gtkrsync_1.0.4-sid-i386-20100604-075618.22.log gtkrsync requires some build-dependencies conflicting each other. I didn't spend a lot of time on this specific issue, so I'm not able to say where the problem is right now. > > I have already informed upstream of my rebuild tests, and I hopefully > > will be given instructions on how to properly fix FTBFSes, which I will > > report as important bugs against affected packages. SCons 2.0 release > > should happen in June, if RT does not mind, I intend to upload 2.0 to > > unstable shortafter. > > I'm assuming that this is "just" a new upstream version? i.e. once the > FTBFS packages are fixed and assuming no RC issues in scons itself > appear, there'd be no need for any explicit action from the Release Team > and SCons 2.0 would simply transition to testing once its 10 days were > up? Exactly, given that several packages build-depend on SCons, and there could be some hidden aspects I'm not aware of, informing RT in advance could avoid additional headache to team members :) -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: pid file security
On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton wrote: > apologies for butting-in without being able to continue the thread, > but i've just seen this: > http://advogato.org/person/etbe/diary/779.html > which links to this: > http://lists.debian.org/debian-devel/2010/05/msg00067.html http://etbe.coker.com.au/2010/06/04/securely-killing-processes/ You're quick. I had planned to announce my blog post on this list but forgot before I went to bed last night. For reference the above URL is the best one for my blog post as it allows you to enter comments. > can i please gently remind people that depinit solved the security and > fork-bombing issues years ago. i do keep mentioning depinit, on > debian lists, but there is typically absolutely zero response, which i > do not understand. nevertheless, as a debian and free software > advocate i feel compelled to keep pointing people at solutions: it's > up to you to investigate them. http://sourceforge.net/projects/depinit/ The above URL is one place to download depinit. It's an init replacement that uses configuration files to give the details of services to start. > depinit solved the fork-bombing issue because richard lightman was > concerned about attacks on his internet-facing system. richard added > code which actively tracks child signals (depinit is highly unusual > and innovative in that it catches ALL signals, and can therefore react > _to_ any signal) and analyses the timing etc. and provides a means to > trigger arbitrary "scripts" based on the signal type. How does it do that? Does it ptrace them? > i recall a discussion with richard back in 2004/5 where he said that > when depinit is asked to stop a dependency/service, it does so by > first sending "graceful" signals, then goes on to take increasingly > aggressive action, including deciding, based on child-fork-bombing, > that a service has been corrupted and thus needs to be terminated with > extreme prejudice. http://etbe.coker.com.au/2010/05/16/systemd-init/ How does it prevent processes escaping? Does it use cgroups as systemd does? See the above URL for some of my thoughts about systemd. > richard also solved the security PID problem ... by doing away with > the need for the PID file. That doesn't do away with the need for arbitrary programs to kill other arbitrary programs and not make a mistake about which program they are killing. > in other words, a service is _always_ run > in "foreground" mode. if it dies (i.e. a segfault signal is caught), > the service is restarted automatically - by depinit (based on the > signal alone). thus, the need for safe_mysql goes away entirely; the > need for "apache2ctl start" goes away (i.e. you use apache2 -c > FOREGROUND=True or whatever it is) and so on. in this way, there > simply _is_ no need for a PID file, period. the relevant state > information is contained within depinit itself, and you can guarantee > that depinit will catch the signal. systemd does all that. > and looked for "unauthorised login" attempts. more than three of > those occurring within a specified time, and iptables would be called > to block that user's IP address. voila: no delays due to syslog > polling: instant and real-time attacker blocking, all using simple Does a program that uses inotify to wait for log file changes on disk experience any delay of note? > so i feel compelled to point these things out, along with the other > incredible benefits that depinit brings including _massive_ reductions > in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was > doing about 90 at the time), and phenomenal near-unbelievable > improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when > debian was doing about 60 at the time), as it pains me to see depinit > being totally ignored and these security and painful issues being > discussed _years_ after a solution has already been done, and proven > to be effective. The systemd option of creating sockets before executing services that listen to them seems to offer the potential of more significant boot performance benefits than just starting things in parallel. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- 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/201006051226.24353.russ...@coker.com.au
Bug#583954: fstab doesn't mount external USB-drive, but mount -a does
On Mon, May 31, 2010 at 10:34:01PM +0200, André Fliß | Planet Groove Productions wrote: > While booting Debian does not recognize the external USB-harddisk. It is not > mounted. > I've been hit by the same problem, and seemed to find a workaround by using package usbmount. It's not perfect, but seems to at least relieve from the pain ;) Hope this helps. Best regards, -- Olivier BERGER (OpenPGP: 1024D/B4C5F37F) http://www.olivierberger.com/weblog/ -- 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/20100605053845.ga8...@olivierberger.com
Re: pid file security
]] Russell Coker | > in other words, a service is _always_ run | > in "foreground" mode. if it dies (i.e. a segfault signal is caught), | > the service is restarted automatically - by depinit (based on the | > signal alone). thus, the need for safe_mysql goes away entirely; the | > need for "apache2ctl start" goes away (i.e. you use apache2 -c | > FOREGROUND=True or whatever it is) and so on. in this way, there | > simply _is_ no need for a PID file, period. the relevant state | > information is contained within depinit itself, and you can guarantee | > that depinit will catch the signal. | | systemd does all that. More importantly: systemd _allows_ them to do that, it doesn't require them. From the description of depinit, it sounds like it requires all daemons to be modified. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ocfqhuiw@qurzaw.linpro.no
