Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Mon, Apr 16, 2012 at 7:15 PM, Arno Töll wrote: > On 16.04.2012 18:59, Olaf van der Spek wrote: >> Defining a standard for vhosts would solve the problem without having >> to touch the normal doc root. Seems like a far simpler fix. > > how would you do that? We can't control or enforce what directory people > pick for their virtual hosts. We do not and can not configure any > virtual host beyond a default. Ensure default conf and examples use /srv/ See lighttpd's simple-vhost conf. You could do the same in vhost_alias.conf You could also provide an site.example file in sites-available > Of course we could just write some docs and tell people "please use /srv > for your personal vhosts", but that's not going to solve the problem I > want to address. Most people generally do not read documentation and > those who do, most likely already realize using the default /var/www > vhost plus custom /var/www/site vhosts causes problems. You're right, solving this via docs is not a good approach. > Hence I advocate to configure the default as sane as possible to obey > the principle of least surprise. > > -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D > -- Olaf -- 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/CAA7U3HM_ht6PK8SwgGVHB4uNvWOebiRBNkye=goresfafts...@mail.gmail.com
Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Mon, Apr 16, 2012 at 7:21 PM, Arno Töll wrote: > Hi, > > On 16.04.2012 18:56, Olaf van der Spek wrote: >> On Sun, Apr 15, 2012 at 1:14 PM, Paul Wise wrote: >>> /srv is solely the domain of the sysadmin, packages cannot rely on any >>> particular layout not specified by the sysadmin (via debconf etc). >> >> I know. Is that a problem though? >> AFAIK packages don't (and shouldn't) put any files into vhost dirs. > > A document root served from /srv would include the HTTP base directory, > e.g. /srv/www or similar with a default document root /srv/www/htdocs > which would include a index.html file at very least. You ship that at > Lighttpd as well. Using /srv for vhosts does not require the default doc root to be under /srv too. The default doc root could stay at /var/www Olaf -- 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/CAA7U3HNFS_0km-qoqoJVkfVnpa=lhbzq1orwoqx+ikqg+cs...@mail.gmail.com
Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Sun, Apr 15, 2012 at 5:49 PM, Arno Töll wrote: >> I'd use ht instead of html. Not every ht file is a html file. > > I have no strong opinion on the actual name, as long as it is another > subdirectory. We could equally use /var/www/default, /var/www/htdocs or > whatever we feel like. What about vhosts? Defining a standard for vhosts would solve the problem without having to touch the normal doc root. Seems like a far simpler fix. Olaf -- 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/CAA7U3HNvBnTDV=qxupl53mwl_isrtj4lbceekxq42undiaa...@mail.gmail.com
Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Sun, Apr 15, 2012 at 1:14 PM, Paul Wise wrote: > /srv is solely the domain of the sysadmin, packages cannot rely on any > particular layout not specified by the sysadmin (via debconf etc). I know. Is that a problem though? AFAIK packages don't (and shouldn't) put any files into vhost dirs. -- Olaf -- 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/caa7u3hmduxnu8sdwnwucnztt8q7e7p5dbrwlao+ytyew-qk...@mail.gmail.com
Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Sun, Apr 15, 2012 at 1:12 PM, Thomas Goirand wrote: >> I'd use ht instead of html. Not every ht file is a html file. >> >> We should consider vhosts as well. Lighttpd defaults to >> /srv//htdocs (for mod simple vhost). ht instead of htdocs might >> be better. >> >> We could use /srv/default/ht as the default doc root. >> FHS: /srv : Data for services provided by this system. The methodology >> used to name subdirectories of /srv is unspecified as there is >> currently no consensus on how this should be done. >> > Moving to anywhere outside of /var is a bad idea because this might > fill up space on the rootfs, while /var is traditionally (at least on > servers) a separate partition. That's what you get with silly partitioning. :p FHS says /srv contains site-specific data which is served by this system. Besides, it's the admin that's going to populate the space, so if it's not enough, he can change the location. -- Olaf -- 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/caa7u3hofqplsqhhm7uqjwqzja57pqsmo91veupbmeudk2a6...@mail.gmail.com
Re: [pkg-lighttpd] Changing the default document root for HTTP server
On Sun, Apr 15, 2012 at 2:25 AM, Arno Töll wrote: > Thus, to summarize once again: I'd like to change the default directory > served by web servers from /var/www to /var/www/html along with > remaining web servers in Debian. > > Comments? I'd use ht instead of html. Not every ht file is a html file. We should consider vhosts as well. Lighttpd defaults to /srv//htdocs (for mod simple vhost). ht instead of htdocs might be better. We could use /srv/default/ht as the default doc root. FHS: /srv : Data for services provided by this system. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. Please CC me -- Olaf -- 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/caa7u3hpvn6ztpjguuyubzwyklfgw2x1oboj_y3gdkamx5u7...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Mon, Mar 28, 2011 at 6:43 PM, John H. Robinson, IV wrote: >> Compatible with what? Bugs in other implementations? >> What does that really gain us? > > The ability for the discs to be read on as many systems as possible. I'm > not going to pretend to know what all someone else may need to do with > the data, but making it as readable as possible is certainly a laudable > goal. Sure, but is it more important than other goals like supporting long filenames? > A plausible scenario is someone having downloaded the images, burned > them, and is now trying to read them prior to installation. If they are > performing this on a Microsoft or Apple OS, and the filenames are > corrupted, the implication is that the images are either corrupt or the > burn was otherwise bad. What Apple and MS OSs are affected? -- Olaf -- 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/AANLkTin-dxD5Nq3XKmuUs=2EJ=JzHMFFbhtxHkaep=j...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV wrote: >> That's not our problem, is it? > > It is, if we are trying to be as compatible as possible. Compatible with what? Bugs in other implementations? What does that really gain us? -- Olaf -- 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/AANLkTi=fhm8tko5mv9pcu9-r8ua23yw2hqsn2ckyq...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre wrote: >>Why's that? Isn't UDF widely supported? > > Implementations often widely differ in their limitations - see the > Wikipedia page for more details. The suggested way to make a safe UDF > DVD is often along the lines of "use the ISO9660 bridge format". :-( That's not our problem, is it? -- Olaf -- 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/AANLkTi=vxP9uJ8PdnuMQ3HKK=R5d05S+RD-jcfcNO5=q...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre wrote: >>64 is quite low. Is there no way to use longer filenames that still >>works on all required platforms? > > To do that, we'll have to switch to a different filesystem. That's a > possibility (maybe UDF), but there's probably even more of a chance of > compatibility problems then. Why's that? Isn't UDF widely supported? -- Olaf -- 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/aanlktikog-er7p3d2azypdf4vwbffgep78i+t9m2r...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre wrote: > users. The problem is that Joliet has a limit for filename length (64 > characters), and technically we're already past that length. From > genisoimage.1: 64 is quite low. Is there no way to use longer filenames that still works on all required platforms? Olaf -- 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/aanlktikn-bvcodvxp6hhhz-n9qr+we7edt7avsub1...@mail.gmail.com
Re: enable/disable support in /usr/sbin/service
On Fri, Mar 4, 2011 at 12:35 PM, Stefano Zacchiroli wrote: > On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote: >> At present there *is* no reliable sysadmin interface for enabling/disabling >> services. update-rc.d is not it; many admins have been using 'update-rc.d >> -f remove' for years, but this is /wrong/ and it is /documented/ that this >> will cause the links to be readded on package upgrade. policy-rc.d is not >> it; the spec for this is bloated and I've never heard of an admin who's ever >> bothered implementing anything more than a "don't start any services in a >> chroot" policy using this. And /etc/default/* isn't it; no consistent >> variable naming, not implemented for all services (and shouldn't be), so >> it's not scriptable, so it requires vi. >> >> So the mv command above *is* the current method. And we're in desperate >> need of a better one. > > Right, this is the technical problem to solve: find one (handy) method > to enable/disable services and "bless" it as the recommended one. http://packages.debian.org/squeeze/chkconfig ... -- Olaf -- 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/AANLkTin1+=xxs7ezab+apt2vgrzq7rttan5b5roym...@mail.gmail.com
Re: Library depending on -data packages
On Mon, Mar 21, 2011 at 5:42 PM, Simon McVittie wrote: > The data package typically just takes up space without doing anything > useful if you install it on its own, so it should have the > special::auto-inst-parts debtag and should usually Recommend the library or > executable. I don't agree. Yes, the data isn't very useful without the code, but that doesn't mean it should depend or recommend the code. When you want to play Quake, you don't install Quake-data (or whatever it's called), you install the pkg containing the executable. -- Olaf -- 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/AANLkTikFXRFb4-8r5krHc3nq_=vl93ameu9ibzvg+...@mail.gmail.com
Re: enable/disable support in /usr/sbin/service
On Sun, Mar 20, 2011 at 7:43 AM, Raphael Geissert wrote: >> | In particular, considering the possibility of other init systems coming >> | (see #591791), would /usr/sbin/service enable/disable still be a proper, >> | init-system-independent, abstraction? >> >> I'm guessing service would have to learn how all other init systems >> work, or have a way to tell them when they are installed (so «install >> foo; disable foo ; change init system» still leaves foo disabled). > > I started a discussion about this topic but with another focus: > http://bugs.debian.org/588085 > (message #21 is the one closest to this thread) service is the UI and invoke-rc.d is the API for starting/stopping services. chkconfig (not yet available) is the UI and update-rc.d is the API for setting when services should be started/stopped. One issue you mention is that services are started by logrotate when they weren't running before. This should be solved by clearly defining the semantics of the actions used and by simplifying init scripts (reducing code duplication / moving code to libs). -- Olaf -- 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/aanlktimmumxff0eglheftcfct3fnw7k1zwcxvvu3r...@mail.gmail.com
Re: potential MBF: first alternate depends not available in main
On Fri, Mar 18, 2011 at 3:10 PM, Bernhard R. Link wrote: >> Like say: In 10+ years I have never ever seen a single rar file >> unrar-free could unpack but thousands that needed unrar/rar. > > If that was true then unrar-free should be dropped and everything > depending on it be removed, too, or moved to contrib. It probably should. -- Olaf -- 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/aanlktim0yn36fk4s7bx1doqv78fjaotncc_jahrjj...@mail.gmail.com
Re: Speeding up dpkg, a proposal
On Fri, Mar 18, 2011 at 12:11 AM, Russell Coker wrote: >> Then don't use the option. It should definetly be an option: > > It's a pity that there is no kernel support for synching one filesystem (or > maybe a few filesystems). That'd be only a partial work around. Even with a single fs one big sync can be bad. > I recently had a situation where I was doing a backup to a USB flash device > and I decided to install some Debian packages. The sync() didn't complete > until the backup completed because the write-back buffers were never empty! Didn't dpkg stop using sync? Olaf -- 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/AANLkTi=sjgv2n_otcrgymw8zvqo0pgd9zz_1+dquu...@mail.gmail.com
Re: Mirror problems?
On Tue, Mar 15, 2011 at 4:51 PM, Bernd Zeimetz wrote: > On 03/15/2011 04:17 PM, Lucas Nussbaum wrote: >> Indeed, I don't know why we bother with packages at all. > > Thanks for your constructive comment. He's right though. With packages, you can receive automatic notification of available updates. Olaf -- 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/aanlktim6w1+nqiqlnirk9qwbzpv8bvt5sgjewleko...@mail.gmail.com
Re: Setting file capabilites of files shipped in binary packages
On Mon, Mar 14, 2011 at 2:17 PM, Ben Hutchings wrote: > On Mon, 2011-03-14 at 09:17 +0100, Sebastian Harl wrote: > [...] >> > > Would it be fine to do that in postinst? >> > >> > It must be done in postinst, and you may need to fall back to setuid if >> > the filesystem does not support setcap. >> >> Do you know of a way to find out if the filesystem supports setcap >> (other than trying out ;-))? > > No, I don't think there's a way to do that programmatically. You would > just have to try capset and then chmod u+s. Shouldn't this be done via DH instead of duplicating this code into lots of postinsts? -- Olaf -- 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/AANLkTi=gnudgc6cvqn4hvg2my9zrvrn2ytmvlobe+...@mail.gmail.com
Re: "epollCreate: unsupported operation" on buildd hosts
On Wed, Mar 9, 2011 at 11:09 AM, Adam Borowski wrote: >> Or is it actually so that the libc should map uses of epoll_create1 to >> epoll_create? Or do we need to introduce run-time checks as to whether >> epoll_create1 is available? > > There's no way around run-time checks if you want to be safe from this race, > yeah. It can be done either in libc or in your code; the former means less > code duplication but hurts badly any backporting. Why is the function declared but not implemented? Seems kinda silly. Olaf -- 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/AANLkTi,xNzNvk1M=wkawxjtzfs5m3dzrfnyu4vh...@mail.gmail.com
Re: re buildd's resolver and package's build deps
On Sun, Mar 6, 2011 at 4:36 PM, Joachim Breitner wrote: > I have a bit a bad feeling about not being able to use alternatives in > build-depends. For example at the moment, we are renaming a self-hosting > compiler package from ghc6 to ghc. Previously, the dependency has been > on "ghc6". Now it is "ghc | ghc6", at least for the transition period, > and it would be a shame if the buildds would (do?) not cope with that. What about renaming the pkg, have the new one provide the old one and continue depending on the old name until the new name is widely available? -- Olaf -- 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/AANLkTi=zv3juraf3j8puw1jkt3fkv4dj-gzeh-wew...@mail.gmail.com
Re: Disable ZeroConf: how to ?
On Fri, Mar 4, 2011 at 3:59 PM, Klaus Ethgen wrote: > In ancient times debian was packaged the way that the administrator only > installed the daemons that he needed. Today many daemons gets installed > by dependencies and gets started without any need. Just the fact is > security relevant as any running daemon higher the change that there is > a security hole. Every daemon! And examples are found at many places > today. I. e. mysqld from kde packages, apache for a linkchecker, avahi > and consortions for gnome, ... Not to mention all the daemons that do > not listen on network as gconf, kded4, ... Daemons that don't listen on a public interface are less of an issue. But in general I agree, daemons shouldn't run without need, especially not on public interfaces. > I think, in the last few years, the quality of (some) debian packages > has sunken. But this is just my personal view, and I am sorry to say it. > > If you want to change debian to be ubuntu it would be the time to look > for another distribution that can be used on servers. (unfortunately I > do not know an alternative.) Actually "Ubuntu ships with no open ports on public interfaces" (by default). It's also silly to launch another distro just because some settings have to be changed. -- Olaf -- 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/AANLkTin79bF3bbeNVV=R_fUy_2=txhj2yczeka9wd...@mail.gmail.com
Re: Disable ZeroConf: how to ?
On Fri, Mar 4, 2011 at 1:23 PM, Ben Hutchings wrote: > You could stop being lazy and type the dot on the end too. ;-) You can't expect everyone to type a dot after every single domain name they use. Olaf -- 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/AANLkTimTneETbdrpTQwG3Y0hFU1T9XbeWu=ksnwr7...@mail.gmail.com
Re: enable/disable support in /usr/sbin/service
On Fri, Mar 4, 2011 at 12:35 PM, Stefano Zacchiroli wrote: > Right, this is the technical problem to solve: find one (handy) method > to enable/disable services and "bless" it as the recommended one. What do other distros use? It seems to be chkconfig, not service (for this functionality). Olaf -- 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/aanlktikr_vteysmvkb-zbzcysorktjtriw7syy+wb...@mail.gmail.com
Re: Speeding up dpkg, a proposal
On Thu, Mar 3, 2011 at 7:32 PM, Phillip Susi wrote: >> And we use some linux specific ioctl to avoid that fragmentation. > > Could you be more specific? sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE); sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); Olaf -- 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/AANLkTimBZq=piivirm+o+rhzt5d-trmcbn6kncy2m...@mail.gmail.com
Re: Disable ZeroConf: how to ?
On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius wrote: > On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote: >> some package announce their existance to the world without any admin >> decision! >> It is not a fud and a security hole! > > That's a vague generality... which packages? You mentioned phpmyadmin. > What are the actual problems that results from this announcement? What > bad things happen from it? Can the fact that you have phpmyadmin become > known to an attacker via port scanning, or similar techniques? If so, > does it matter if phpmyadmin also announces things via avahi? What do > you suggest as a solution? Would a blanket policy of having all services > to default to not announce themselves? What would the problems from such > a policy be? > > (I don't know much about this stuff, and I don't particularly care, but > it'd be nice if we could turn the discussion into a constructive one.) Windows has the concept of home / private and public networks. On public networks, sharing gets disabled. Such a concept would be good for this situation as well. Let the user indicate what type of network he is on and what type of services should be opened to that network. Olaf -- 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/aanlktintbslqb6ertkoab3ulxsx+wwjjemxk-lxe9...@mail.gmail.com
Re: enable/disable flags in /etc/default
On Thu, Mar 3, 2011 at 7:25 AM, Tollef Fog Heen wrote: > - install daemon > - install configuration using puppet/chef/cfengine/etc > - start daemon or hook daemon into tool that keeps it running (monit, > god, etc) Can't you either install the config before installing the daemon or just do a daemon restart afterwards? -- Olaf -- 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/aanlktimvps6izoe0uyggnv1ou1am6f2_wysy4gym1...@mail.gmail.com
Re: Speeding up dpkg, a proposal
On Thu, Mar 3, 2011 at 8:33 AM, Marius Vollmer wrote: > And in the big picture, all we need is some guarantee that renames are > comitted in order, and after the content of the file that is being > renamed. I have the impression that all reasonable filesystems give > that guarantee now, no? No, they took shortcuts in the implementation and commit the rename before the source file. > Hmm, right. We could keep a list of all files that need fsyncing, and > then fsync them all just before writing the checkpoint. Instead of fsync you might want to use the async Linux specific sync options. -- Olaf -- 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/AANLkTinW=kxn2trssg+b327prv5m66-zpdxc0s10l...@mail.gmail.com
Re: enable/disable flags in /etc/default
On Tue, Mar 1, 2011 at 7:25 PM, Sean Finney wrote: > well, for starters the interface sucks from a sysadmin point of view > compared to stuff like chkconfig/service. i also think that there's (a > perhaps shrunken, haven't checked in a while) set of things that you > just can't do with update-rc.d, without having the changes lost the next > time the package is upgraded. i mean, it's not even that great for > maintainer scripts, as evidenced by the total inconsistency for how > developers are managing enabling/disabling of their services. Isn't that handled by DH for simple cases? -- Olaf -- 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/AANLkTinPMkd44DNhmiE=1uP4NWsC56T4Z=avxvmt5...@mail.gmail.com
Re: enable/disable flags in /etc/default
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek wrote: > On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote: >> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote: >> >> Isn't update-rc.d the way to configure the rc.d scripts? > >> > No, it's a way for *maintainer scripts* to manage init scripts. > >> >> Or am I old-fashioned. > >> > You are using an interface that was never meant for administrator use. >> > Nowadays there's an 'update-rc.d enable/disable', but even that, I think, >> > was intended to be a backend for the 'service' command. > >> So what *is* the proper UI? > > The sensible abstraction for this is 'service' - but it doesn't appear that > service has support for enable/disable yet :( Do other distro's use service for this? What's the reason update-rc.d is limited to maintainer scripts? Olaf -- 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/AANLkTi=s+yx_pgdg_+inbutmbg4fn4hrd-njphgug...@mail.gmail.com
Re: enable/disable flags in /etc/default
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote: >> Isn't update-rc.d the way to configure the rc.d scripts? > > No, it's a way for *maintainer scripts* to manage init scripts. > >> Or am I old-fashioned. > > You are using an interface that was never meant for administrator use. > Nowadays there's an 'update-rc.d enable/disable', but even that, I think, > was intended to be a backend for the 'service' command. So what *is* the proper UI? Olaf -- 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/AANLkTi=3M7q=KgNVmY5q=hvfb8bwmhelkbjp4jdxl...@mail.gmail.com
Re: Potential memory leaks reported by Valgrind against some frequently used commands
2011/3/1 ximalaya : > I notice that, valgrind reports memory leaks against some frequently used > commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps > -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. -- Olaf -- 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/aanlktikrvavkxvzjgltmgrqerca7fxii9hdl8mhvp...@mail.gmail.com
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh wrote: >> But there is an ordering choice. local has priority. > > By default, we assume the local administrator knows what he is doing. > > That is not going to change. Sure. But Sergey has a good point: why are there no bin and lib inside /home so normal users can safely install software without risking system-wide things to go wrong? -- Olaf -- 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/AANLkTi=mf=qhhvkqeazu7fuzipteib_6+p8gixwpb...@mail.gmail.com
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library
On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson wrote: > Unfortunately (from your perspective) there is not a way to configure a > default library search path differently for binaries in different > places. So if you want /usr/local/bin binaries to see /usr/local/lib > by default (that's what Debian and other Linux systems do, on purpose), > then all your system binaries will see them too. Anyway, it's not a > bug or even really a design flaw (IMO). But there is an ordering choice. local has priority. -- Olaf -- 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/aanlktiky94dbkx3icgmqt40th00uk3by+s7a2tcxx...@mail.gmail.com
Re: linker related changes for wheezy
On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos wrote: > Those are valid points, of course, but many Boost projects will fail > to build now and I see no good solution[1][2][3]. Some libraries like I do: http://en.wikipedia.org/wiki/Auto-linking First has to be implemented in GCC though. -- Olaf -- 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/aanlktik5szndl4xten0k5b0rrhygimjjztyi14e_v...@mail.gmail.com
Re: [Adduser-devel] Default Homedir Permissions
On Sat, Feb 19, 2011 at 10:49 AM, Olaf van der Spek wrote: > On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran wrote: >> I don't want to prolong this thread, but this seemed useful to answer. >> >> I certainly have no intention of changing the default on my own. > > Could you at least fix the original bug and ensure preseeding works? Stephen? -- Olaf -- 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/aanlktikp0esxaqqwv5et4vvswgeeengd+gtp-v-y7...@mail.gmail.com
Re: Bug#612752: Bind fails to start if $OPENSSL_CONF is set
On Fri, Feb 25, 2011 at 9:55 AM, Peter Palfrader wrote: > We should probably start a campaign in Debian to have all init scripts > sanitize the environment of daemons they start. > > I usually run initscripts using "env -i /etc/init.d/$foo start" to > achieve exactly that, but ideally the init script itself would do that. > > Maybe start-stop-daemon should have an option to delete all but a > specified set of environment variables, maybe even enabled by default. Why start-stop-daemon? I'd create /lib/deb/init-functions and either supply a function to sanitize the environment or do this automatically. -- Olaf -- 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/AANLkTin1kt2EyMU2n0ume+oJnf+TFRnd=pdh+z4ex...@mail.gmail.com
Re: Default Homedir Permissions
On Sat, Feb 19, 2011 at 11:43 AM, Roger Leigh wrote: > We could even do the opposite (create a "public" folder) if the > permissions are 0750, though this would require either 0751 or > ACLs to be actually accessible. Again, we could include a README file > instructing the user how to do this. Or it could be a symlink to a public user dir outside of /home such that 751 isn't necessary. Olaf -- 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/AANLkTinzOaT5=LQTxxeQHkR=rhnbrkvtypewukxeh...@mail.gmail.com
Re: [Adduser-devel] Default Homedir Permissions
On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran wrote: > I don't want to prolong this thread, but this seemed useful to answer. > > I certainly have no intention of changing the default on my own. Could you at least fix the original bug and ensure preseeding works? Olaf -- 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/AANLkTi=ukk0rcjcunyma7e9d7rkojvnbyrkzalu0j...@mail.gmail.com
Re: Default Homedir Permissions
On Sat, Feb 19, 2011 at 9:10 AM, Marc Haber wrote: >>On Thu, Feb 17, 2011 at 01:44:26PM +, Ian Jackson wrote: >>> Perhaps it might be reasonable to try to find a way for accounts like >>> msql and www-data not to be able to access home directories (add >>> "daemon" to their supplementary group list and set the permissions of >>> /home 0705 to root.daemon, perhaps), but is this really worthwhile ? >>> If it is, the right thing to do is to go away and think about exactly >>> how to do it, not to file a bug asking for the default home directory >>> permissions to be changed. >> >>This is easily accomplished using ACLs. > > Please, don't force this on a default install. Force what? ACLs being usable by default or ACLs being used? -- Olaf -- 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/AANLkTi=zjRhJ2t7E+gKytC9ts1gy=ypkqenklspp1...@mail.gmail.com
Re: Default Homedir Permissions
On Fri, Feb 18, 2011 at 2:26 PM, Noel David Torres Taño wrote: > On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió: >> On 02/17/2011 08:58 AM, Roger Leigh wrote: >> [snip] >> >> > Should it be locked down like Fort Knox? >> >> There's a heck of a lot of middle ground between "Fort Knox" and >> "Hippy Commune". > > We are not a hippy comune, just two married people, but I like to hear music > from my wife's home, and she uses to see documents that are on my home, so the > actual default fits quite well for 90% of computers out there: home computers. IIRC many weren't that happy with Windows 9x not supporting access control. I guess times have changed. > Think too on fathers accessing their minor child homes, offices in which > documents are property of the bussiness and not of any worker, etc. What about a minor child downloading a trojan (for whatever reason) which accesses the fathers home? A bug in a web scripts leading to www-data being compromised, and thus having read access to /home? -- Olaf -- 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/AANLkTimFfQ=1rk5_dfsbwe4addrf+guzucgg3dius...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 4:24 PM, Roger Leigh wrote: > On Thu, Feb 17, 2011 at 04:07:12PM +0100, Olaf van der Spek wrote: >> On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote: >> > In general, I think it's fair to say that the average Debian >> > installation does not require Fort Knox levels of security. Simply >> > allowing other people to read our files is often something desirable; >> >> Does other refer to other users, all other accounts or the entire world? > > It refers to S_IRWXO, which is what this bug is about. What that > means in practice is up to you. Other (people) in "Simply allowing other people to read our files is often something desirable" does not refer to S_IRWXO. >> Like backups, the need for security is often discovered after it was >> necessary. > > Yes, but like everything there is a tradeoff. A totally secure system > is an unusable system. Having to instruct every user how to relax the > permissions to allow others to access their files, or allow their web > pages to be visible, is effectively pointless make-work if that was what > you wanted in the first place. You're right, in that case it makes more sense to edit /etc/adduser.conf Or to setup public dirs that people could use to share stuff without defaulting to share their entire home dir. > And for most people, I would argue that > /is/ what is wanted. Is it? A lot of people have desktops / laptops that aren't shared with other people and that don't use the per-user public_html. > Remember that historically, multi-user systems have been about sharing > and collaboration, not isolation in walled-off prisons. I know which > type of system I want, and it's not the latter. Historically security was not an issue. > 0755 is not inherently insecure. Others can't make any changes, but > they can look. The only issue here is accidental disclosure of > information intended to be private. Right -- Olaf -- 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/AANLkTi=4R87hRmXQc4Y7zL9b5KJ0yJqtTYXeX80MQN=p...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote: > In general, I think it's fair to say that the average Debian > installation does not require Fort Knox levels of security. Simply > allowing other people to read our files is often something desirable; Does other refer to other users, all other accounts or the entire world? > if I have something especially secret, I'll take steps to make sure > it's not readable or writeable by anyone except me. But in general, > it's not a bad thing that others can see my stuff. I can always keep > private things in a 0700 subdirectory. You can, but you can easily forget that. Note that defaulting to private does not prevent you from changing the permissions. > I can see that in some circumstances you might well want total control > over who can see your files, but unless you're dealing with TOP SECRET > stuff, I am not convinced that this is something the typical user would > wish to have by default. Are there any common use cases which require > this? Like backups, the need for security is often discovered after it was necessary. -- Olaf -- 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/AANLkTim_txyuh+zvXyOXHzWTPf8QypYZHj=s+b4ko...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 3:38 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Default Homedir Permissions"):
>> chmod 755 ~ is not a hard way to remove the barrier.
>
> We are arguing about defaults, so this is not a relevant answer.
In both cases it's easy to change permissions, but:
If you start with safe permissions but want to share everything, you
get an error message. Easy to fix.
If you start with unsafe permissions but wanted to share nothing, you
don't get an error messages and your data leaks. Impossible to fix.
>> What are those assumptions based on?
>
> I could ask you the same question. We are arguing in a vacuum.
Feel free to ask.
--
Olaf
--
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/aanlktins21pvtzze5vkczxomabitubunx90bsye-m...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 2:44 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Default Homedir Permissions"):
>> Default homedir permissions are 755. World-readable (and listable).
>> Common (security) sense says that permissions that are not required
>> should not be granted. For example, accounts mysql and www-data should
>> not have access to my documents.
>
> I disagree with this conclusion, because I disagree with the
> underlying implication that the general readability of files is not
> needed.
> Most installed systems have a smallish number of users who know each
> other reasonably well and would like to be able to share files. It
What are those assumptions based on?
And how do you go from "want to share some files" to "default to share
all files"?
> does not make sense to put strong privacy barriers in between those
> users. Sensitive data like email and browser histories are already
> made non-world-readable.
chmod 755 ~ is not a hard way to remove the barrier.
> So the default is correct.
>
> Perhaps it might be reasonable to try to find a way for accounts like
> msql and www-data not to be able to access home directories (add
> "daemon" to their supplementary group list and set the permissions of
> /home 0705 to root.daemon, perhaps), but is this really worthwhile ?
That would be another violation of general security principles (access
control based on exlcusion instead of inclusion);
> If it is, the right thing to do is to go away and think about exactly
> how to do it, not to file a bug asking for the default home directory
> permissions to be changed.
The bug wasn't about that, although it was related.
--
Olaf
--
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/AANLkTim3=P6Ed-=z+vnpagvfhm-fh+4gn32pbso3m...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 1:52 PM, Martin Wuertele wrote: > IIRC you are asked during installation if you want world readable home > directories or not. No you're not. Unless (I assume) you do an expert install. Even then, non-world-readble means 751, not 750. The default should still change. -- Olaf -- 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/AANLkTi=66vthmh2--ape7jqq4nwv_jdf1rhl17amk...@mail.gmail.com
Default Homedir Permissions
Hi, Default homedir permissions are 755. World-readable (and listable). Common (security) sense says that permissions that are not required should not be granted. For example, accounts mysql and www-data should not have access to my documents. Some time ago I filed a bug related to this: 398793 The maintainer didn't agree and asked me to bring this up on this list. What do you think? The (only) disadvantage is that ~/public_html requires you too grant permission manually. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398793 -- Olaf -- 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/aanlktin3n3j_dxds0zvrhhhfgo9mvvjrpg+yywdvy...@mail.gmail.com
Re: Upcoming FTPMaster meeting
On Tue, Feb 15, 2011 at 6:04 PM, Mark Hymers wrote: > Could we choose to document that it can only be used in wheezy (enforced > by dak if necessary) and above and then have the release notes state > that users must upgrade dpkg and apt to the latest point release before > doing the dist-upgrade? Such things should not be documented. Either it shouldn't be necessary or it should be done automatically. Olaf -- 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/aanlktim15vxykkpc1j2fxtamrtxthwgabvcti5gch...@mail.gmail.com
Re: Upstart and sysvinit in packages - Policy needed
On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen wrote: > ]] Petter Reinholdtsen > > | I believe we need to come up with a way where most or all package > | maintainers (perhaps those handling kernel events and early boot stuff > | should be expected) only need to maintain one boot setup for their > | package, and this boot setup should be used by all the different boot > | systems. > > That would mean limiting each init system to the limitations of the most > limited init system, which would be a sad state of affairs. Also, I Most isn't all. IMO there's way too much code duplication in current init scripts. Most daemons are pretty standard and shouldn't need any special code in their init script. -- Olaf -- 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/aanlktimza__j14yxhh-7hq7kbkqg-vkvowceva2ef...@mail.gmail.com
Re: Upcoming FTPMaster meeting
On Sun, Feb 13, 2011 at 12:58 PM, Roger Leigh wrote: > • adding build conflicts to ensure it will build on any arbitrary > system with a random selection of installed packages will always be > on a "best effort" basis: Is this about automatically picking up optional dependencies (by configure and friends)? -- Olaf -- 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/aanlktimtq6vxbjvf-gm-qcglb2+av+sjdar_vpd97...@mail.gmail.com
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin wrote: >> 128MB would work reasonably. > I think that VPS'es with 128Mb RAM are still sold, not to mention existing > installations. May enable it on x64 first (those 128 mb VPSs are unlikely to run x64) and then see about other archs later. -- Olaf -- 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/AANLkTi=Gpi+w_VfAEvp1wPS3=5vzz5qpstazdrv6p...@mail.gmail.com
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 4, 2011 at 12:47 PM, Fernando Lemos wrote: >> This is possible, however, it is an extra busy work for a user. In any >> case, I think that holding a lock only for downloading is an overkill >> and this can be relaxed. > > As far as I can tell (and please correct me if I'm wrong), when you > do, say, an "apt-get upgrade", apt prepares an upgrade "plan" that > uses a given set of packages. If apt wouldn't lock and parallel to > that you do an "apt-get install", for example, the original "plan" > might not be valid anymore (e.g., new "Breaks" or "Conflicts" were > introduced). So a new plan would have to be created, the user would > have to be asked for confirmation again. Doesn't sound that great. That's the choice of the user. Probably most of the time a change of plan wouldn't be needed. Olaf -- 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/aanlktikjto7gd44nuptrok9gfpd7k0qk6akaqzlcv...@mail.gmail.com
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 4, 2011 at 9:57 AM, Stanislav Maslovski wrote: > This is possible, however, it is an extra busy work for a user. In any > case, I think that holding a lock only for downloading is an overkill > and this can be relaxed. What if you would launch two download-only ops at the same time? Isn't a lock needed in that case as well? -- Olaf -- 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/aanlktimgxj6vtx5qx8xdbzuaaoxb+jgbn0juz2tya...@mail.gmail.com
Re: Upstream "stable" branches and Debian freeze
2011/2/1 Jesús M. Navarro : > So, may I propose (if not already done) a document that outlines with enough > detail what Debian maintenance policy is and why from an upstream point of > view, and then allow for within Stable upgrades for software that has > demonstrated to pursue the same standards as Debian? Kindof a "quality seal" > that will allow to push minor versions: it would mean "more with less" since > Debian maintainers wouldn't need to maintain their own patch sets and they > would know in advance what the "proper" version to pack for Stable is (the > one that upstream publishes for long term maintenance within the time-frame > for the new Stable version). For those upstreamers interested in doing the > things the proper way, they could find Debian people to be knowledgeable and > helpful about it (since they've been doing it for years and it's in their own > interest). It depends on the kind of package and computer whether it makes sense. For production servers, stability is (way) more important. For desktop users and packages like browsers, which might be fast moving, new features might be more important. Upstream for Firefox and Chrome are not going to provide stable branches that are maintained for two+ years. Olaf -- 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/AANLkTinOqYUc=g6gy9ckkjsgfkp6jzs8nxsws0qst...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o wrote: > On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote: >> >> Is there a way to log cases where (potentially) unsafe writes happen? >> Cases like truncation of an existing file, rename on a target that's >> not yet synced, etc. > > Not really, because there are plenty of cases where it's perfectly OK > not to sync a file on close or on rename. Any files created during a > build, for example, can easily be reproduced in the unlikely case of a > systme crash. If you are untaring a source tree, it's fine not to > worry about syncing out the files, since presumably you can always > repeat the untar operation. Or take git; when git is checking out > files into the working directory, there's no reason that has to be > done in a super-safe way. On the other hand, when it is writing the > git object files and pack files, those had better be done safely. At > the end of the day the application programmer needs to understand what > is going on, and write his code appropriately based on the needs of > his application with respect to reliability after a power crash. > > So how can you just log warnings that the program has just done > something unsafe? It's unsafe only if there's no other way to > reconstitute the data that was just written. But that's not something > which is easily knowable. If all potentially unsafe cases could be logged, the log can be analyzed by a human to detect the real unsafe cases such that the developers of those apps can be notified and the apps can be fixed. -- Olaf -- 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/aanlktimbiodsp4qndcozcnp1yr_6rnxjmw7xtdvgs...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Fri, Jan 28, 2011 at 3:26 AM, Ted Ts'o wrote: > On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote: >> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler >> wrote: >> > BTW: KDE4 is a very good example for failure with modern filesystems. I >> > regularly loose configuration files when suspend-to-ram fails even if the >> > configuration of the running programs were not changed. Yay :-( And this is >> > with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. Reaction: >> > none! >> >> Maybe complain to the Linux kernel people instead. > > It won't be just XFS or ext4, but any file system except ext3 (which > has performance problems specifically *because* of an implementation > detail accidentally provided this feature you like), and I think what > you'll find is that most Linux kernel developers will tell you is that > it's a bug in the application. > > If you don't like that answer, you'll find that it's true for any > other OS (i.e., BSD, OpenSolaris, etc.) --- so either KDE needs to > get with the program, or find its users gradually switching to other > windowing systems that have sanely written libraries. > > - Ted > > P.S. There is a kernel options that provide improved ext3 > performance, to wit, CONFIG_EXT3_DEFAULTS_TO_ORDERED=no, which will > also mean that you had better use fsync() if you want files pushed out > to disk. So strictly speaking, it's not even true that KDE4 is > guaranteed to be safe if you use ext3. Is there a way to log cases where (potentially) unsafe writes happen? Cases like truncation of an existing file, rename on a target that's not yet synced, etc. -- Olaf -- 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/AANLkTikHrfBjaBK5=qkSi3b=kbm1jx15r-f10ijla...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Wed, Jan 26, 2011 at 7:25 PM, Hendrik Sattler wrote: > Zitat von "Olaf van der Spek" : > >> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler >> wrote: >>> >>> BTW: KDE4 is a very good example for failure with modern filesystems. I >>> regularly loose configuration files when suspend-to-ram fails even if the >>> configuration of the running programs were not changed. Yay :-( And this >>> is >>> with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. >>> Reaction: >>> none! >> >> Maybe complain to the Linux kernel people instead. > > "suspend-to-ram fails" is the same situation as a sudden power loss. In this > case, it's not a kernel bug. I don't know how KDE4 handles its configuration > files but something is wrong there when I loose config data without changing > any settings in this scenario... I know. It's about a(nother) use case for O_ATOMIC, but the kernel guys prefer workarounds. -- Olaf -- 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/AANLkTi=+2Dffvgg5=bucrwfy7qrrjuwso-q7awf0w...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler wrote: > BTW: KDE4 is a very good example for failure with modern filesystems. I > regularly loose configuration files when suspend-to-ram fails even if the > configuration of the running programs were not changed. Yay :-( And this is > with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. Reaction: > none! Maybe complain to the Linux kernel people instead. -- Olaf -- 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/AANLkTik20C6mCB=vc-pych37zyr_9wexhd5mg5vbw...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Wed, Jan 26, 2011 at 5:09 PM, Goswin von Brederlow wrote:
> typedef struct {
> int fd;
> char buffer[];
> } safe_t;
>
> or what do you mean by invalid C?
Zero length arrays are not valid C AFAIK.
--
Olaf
--
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/aanlktik-gsod2qvvl45ub-ccg_rjb4tk9jg6l+ytu...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Wed, Jan 26, 2011 at 11:36 AM, Goswin von Brederlow wrote: > I think you are dead wrong there Ian. Even if every single program is > dead right (and we know a lot aren't) that means every one of them has > a safe file update function somewhere in it. > > A function doing exactly the same thing in many programms. Doesn't that > just scream for a shared library? If the kernel supported it properly, it'd be even easier and you wouldn't have all regressions. Lacking that, a lib is the next best thing. > Add to that the number of programs that don't yet do file updates in a > safe way and need to be fixed I think the project is a verry good > idea. The unexpected behaviour of ext4 is just a minor implementation > detail to take care for a general safe update function. Some instrumentation to detect such unsafe behaviour would be helpful too. Olaf -- 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/AANLkTimj=78qkXG=xfc3qop5yyydwkpr9v33hx7s_...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Wed, Jan 26, 2011 at 12:22 PM, Adam Borowski wrote:
>> typedef struct {
>> int fd;
>> char buffer[PATH_MAX];
>> } safe_t;
>
> Except, you can't rely on PATH_MAX on any modern system. It's defined in
> Linux headers to an arbitrary value to make old code compile, but for
> example Hurd folks decided to not define it altogether to make buggy code
> fail during compilation rather than on runtime.
That's easily solved by a dynamic allocation.
Olaf
--
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/aanlktim+oteqsqshz3-fxvg-53cf2iyxsdcxgtsbc...@mail.gmail.com
Re: packages with hook interfaces and no documented hook policy
On Fri, Jan 21, 2011 at 5:39 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: packages with hook interfaces and no
> documented hook policy"):
>> On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
>> > If you have better suggestions how to solve this problem, I'm happy to
>> > hear (and implement) them. Until then I would recomment that you run
>> > the upgrade manually so that you have control over when exactly it
>> > happens.
>>
>> An alternative would be to ensure upgrades can be aborted at any
>> moment (always a good idea to avoid problems after (unexpected)
>> crashes).
>
> This is of course supposed to be the case, since no-one actually tests
> it I doubt it is true. See also giant flameware over filesystem bugs.
Ted says there's no use case for it. So maybe people from Debian,
other distros and upstream developers could discuss this together and
then get back to Ted.
> Also making this true would involve making sure that the kernel we are
> hibernating from is always available and selected by default when we
> do the next boot, so that we don't fail the resume due to kernel
> mismatch.
Shouldn't that be done anyway?
Otherwise hibernates will fail after some kernel upgrades.
--
Olaf
--
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/aanlktikzqgtda4fbeeocpxxdcnqjfh9w3-thkl3f0...@mail.gmail.com
Re: packages with hook interfaces and no documented hook policy
On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote: > If you have better suggestions how to solve this problem, I'm happy to > hear (and implement) them. Until then I would recomment that you run > the upgrade manually so that you have control over when exactly it > happens. An alternative would be to ensure upgrades can be aborted at any moment (always a good idea to avoid problems after (unexpected) crashes). -- Olaf -- 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/AANLkTi=Lrd+7dzeABo=DHLweZWXMUk-g0w0afeYQOK4=@mail.gmail.com
Re: Forwarding bugs upstream
On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko wrote: > Then, maybe explicitly request upstream - at appropriate forums and in > appropriate polite wording - to help debian team(s) to handle the bug > report stream? I think upstream has the same problem in some cases: too many bug reports. So I doubt upstream has time to look at yet another bug tracker. -- Olaf -- 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/aanlktinq4tedjy6jcw_m0dmjxkz8pvtcydoeovper...@mail.gmail.com
Re: packages with hook interfaces and no documented hook policy
On Tue, Jan 18, 2011 at 10:41 AM, Michael Biebl wrote: > On 18.01.2011 06:08, Joey Hess wrote: >> Michael Biebl wrote: >>> Also; You said, the hook breaks suspend/hibernate. I don't agree this is the >>> case. If there is no upgrade running, the hook will exit immediately. >>> If there is an upgrade running, the hook simply blocks until the upgrade has >>> finished. Suspend/Hibernate is still not 100% reliable, so this is probably >>> a >>> safe choice. >> >> ... unless the system is being suspended because it is critically low on >> battery, and is going to crash and lose the user's work and need a fsck >> otherwise. >> >> Suspend may not be 100% reliable on all hardware or in all >> circumstances, but that is not a good excuse to make it significantly >> less reliable, really. > > Sure, as already said, it is a trade-off. > > Starting an upgrade when the system is on (low) battery is certainly not a > good > idea. > I don't know how unattended-upgrades works, but it could skip the upgrade if > the > system is running on batteries. Even then you probably don't want to hibernate when an update is in progress. -- Olaf -- 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/AANLkTikuCGYPmRfhA=6d0b0iqow55oeqkr2ue5sqs...@mail.gmail.com
Re: Why is help so hard to find?
On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery wrote: > It's the responsibility of packages to clean up obsolete conffiles as > they're upgraded. If you run into the case of a package that's been > upgraded and not cleaned up its obsolete conffiles, and there isn't some > reason for that, that's worth a bug report. Too late for this release, > probably, of course Shouldn't this be the responsibility of the package manager? Otherwise it sounds like a big code duplication problem. Olaf -- 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/AANLkTincbMNFysJ=m4r-sj9qryasmw2kk22eth0e0...@mail.gmail.com
Re: Can insserv made better?
On Sun, Jan 16, 2011 at 2:47 AM, Mike Bird wrote: > On Sat January 15 2011 16:33:28 Olaf van der Spek wrote: >> If insserv meses up so bad, shouldn't it be able to detect that things >> will go wrong too? > > insserv completely discards the Snn/Knn values and generates a new > boot ordering based on much less information and which consequently > fails more often. AFAIK insserv doesn't guess. "Much less info" is the dependencies listed in the scripts themselves, right? Isn't this enough? Is the problem insserv itself or wrong dependency lists? Olaf -- 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/aanlktim6fe6be7lwnckidg9nudvnqtxqv8_mrijac...@mail.gmail.com
Re: Can insserv made better?
On Sat, Jan 15, 2011 at 11:39 PM, Mike Bird wrote: > I have looked at the release notes, what little documentation there > is, and much but not all of the source code. > > It would certainly help if a warning were included in the release > notes but the most critical fix is to the misleading statement in > sysv-rc.postinst that enabling insserv is "recommended" with no > warning about the potential adverse consequences. If insserv meses up so bad, shouldn't it be able to detect that things will go wrong too? Got a concrete example of a case that fails? Olaf -- 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/AANLkTi=A1DBU10W5SQzeTq+0n0ybEX9Laf=h+8tqz...@mail.gmail.com
Re: Why is help so hard to find?
On Sat, Jan 15, 2011 at 10:13 AM, Stéphane Glondu wrote: > Le 15/01/2011 01:05, Roger Leigh a écrit : >> This is mostly due to removed packages which need fully purging to >> remove the last traces of old init scripts which break the process. > > I've already experienced issues with configuration files from > uninstalled packages lying around. It wasn't with insserv, nor > initscripts... I don't remember exactly the circumstances. It was years > ago. My conclusion back then was to always purge uninstalled packages, > and so I do on most machines I administrate. Couldn't that be done automatically if no local changes are present? Olaf -- 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/aanlktintr-e1k8fzmx_xvcyykzoggnnupz_uhwqs2...@mail.gmail.com
Re: Forwarding bugs upstream
On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl wrote: > Hi! > > Am 13.01.2011 11:54, schrieb Olaf van der Spek: > >>> Now we just need to define what a proper job is. >> Instead of stepping down, it might be better to ask for a co-maintainer. > > You mean like this http://www.debian.org/devel/wnpp/help_requested? > Let's have a look: > > # chromium-browser [..] requested 228 days ago. > # dpkg [..] requested 2245 days ago. > # grub2 [..] requested 2439 days ago. > # libreoffice [..] requested 1368 days ago. > > Any other good ideas? Perhaps something new ideas, which isn't already > practices? There are lots of packages with old bugs without any comments that are not on that list. Olaf -- 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/aanlktikbtzecpfqqz_0mfgpycxtyq5tnh_i+yycvq...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 2:25 PM, Stefano Zacchiroli wrote: > On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote: >> > Remember: there is no shortage of bug reports. >> >> That's unfortunately true. Why is it that bug squashing parties only >> happen a short time before release while it appears that the rest of >> the time the issue is ignored? > > Please, don't indulge toward trolling :-). There is no cabal^Wsecret > power in Debian who decides when to organize things and when to not > organize them. It's about improving quality, not about trolling. > BSP can be organized whenever you want but, as a matter of fact, they > get organized only when somebody volunteer to do that. If you want to > have a BSP, say, the 1st day after the release of Squeeze, you just have > to organize one. For packages that drown into bug *reports* due to > their popularity, you might also want to organize specific *triaging* > campaigns (better if in coordination with maintainers); they will > relieve the burden of maintainers in doing triaging and let them focus > on actual bugs that random BSP-participants might not feel entitled to > fix. The point is focus on solving bugs shouldn't be limited to BSPs and the end of the release cycle. Olaf -- 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/AANLkTinfL++na7Ra0aKaHm-ZDAKvx1gaua1ErF==k...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 1:40 PM, Ian Jackson wrote: > Remember: there is no shortage of bug reports. That's unfortunately true. Why is it that bug squashing parties only happen a short time before release while it appears that the rest of the time the issue is ignored? -- Olaf -- 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/AANLkTi=kvzedjaa38+yhcpegw1ocaaad0fchgxkur...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 11:27 AM, Sune Vuorela wrote: > On 2011-01-13, Felipe Sateler wrote: >> We can't demand or require anyone to do anything. Yet we expect > > I think this is mostly wrong. > > We can demand or require people to step down. And we should if we don't > think they do a proper job. > > Now we just need to define what a proper job is. Instead of stepping down, it might be better to ask for a co-maintainer. Olaf -- 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/AANLkTi=ga+ve+kqy0ksar6dhbqvs8wnykoux8cplf...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 1:38 AM, Ian Jackson wrote: > But in this case I don't think we should be "expecting" maintainers to > necessarily shepherd bug reports upstream. I don't think a maintainer > who fails to do so is failing in their job as maintainer. > > The maintainer should decide whether they think doing that is a useful > thing to be doing for that package or that bug, and communicate this > decision to the user (and set the bug state accordingly). Maybe some tools (PTS) should warn about bugs that are older than X days and are still unclassified? Olaf -- 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/aanlkti=vahvnar2du9u7r8udza8jcmmh76u0+6wnd...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela wrote: >> Will this mean that the problem will somehow disappear from Debian? Because >> if it's a problem detected within Debian it's my feeling that it will have to >> be tracked within Debian till the problem is in Debian no more. > > No. but it is a way to be honest about teh issue: We are not spending > debian time on fixing it. That's better than no response to a bug report at all. Olaf -- 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/aanlkti=iivsnrccew4v_p-c_faho6arofrgfdbt8=...@mail.gmail.com
Re: Security implication of using force-reload instead of restart ?
On Sun, Jan 9, 2011 at 5:31 PM, Stefan Fritsch wrote: >> Shouldn't libapache2-mod-php5 be deprecated in favor of PHP via >> FastCGI anyway? Would avoid this and other issues. > > mod_php won't go away quickly. Why not? > But having an out-of-the box usable > php+fastcgi configuration in squeeze+1 would be nice. Volunteers > welcome ;-) Olaf -- 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/aanlktikge+n2-9z3un-1zmfdejh1+zgsm-g8vkg=+...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 7:59 PM, Enrico Weigelt wrote: > * Olaf van der Spek schrieb: > >> A transaction to update multiple files in one atomic go? > > Yes. The application first starts an transaction, creates/writes/ > removes a bunch of files and then sends a commit. The changes > should become visible atomically and the call returns when the > commit() is completed (and written out to disk). If there're > conflics, the transaction is aborted w/ proper a error code. > So, in case of a package manager, the update will run completely > in one shot (from userland view) or not at all. > > I could live with: > > a) relatively slow performance (commit taking a second or so) > b) abort as soon as an conflict arises > c) files changed within the transaction are actually new ones > (sane package managers will have to unlink text files instead > simply overwriting nevertheless) That would be nice, but the single file case appears to be difficult enough already. So we might want to focus on that first. Olaf -- 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/aanlktimegmsjdukzghfpnikvipahnz6hb3bjpemtb...@mail.gmail.com
Re: Security implication of using force-reload instead of restart ?
On Sun, Jan 9, 2011 at 10:14 AM, Stefan Fritsch wrote: > No. Apache unloads and reloads modules on a graceful restart, unless a > modules takes special measures to prevent that. You can check that > with lsof or checkrestart. But libapache2-mod-php5's behaviour is not > optimal for other reasons (see #589386). Shouldn't libapache2-mod-php5 be deprecated in favor of PHP via FastCGI anyway? Would avoid this and other issues. Olaf -- 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/aanlktinhtwmzba4scuh2eqm9f8n-5hwiqp0ltywad...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 7:33 PM, Enrico Weigelt wrote: > To come back to the original question, I'd like to know which concrete > realworld problems should be solved by that. One thing an database-like > transactional filesystem (w/ MVCC) would be nice is package managers: > we still have the problem that within the update process there may be > inconsistent states (yes, this had already bitten me!) - if it would > be possible to make an update visible atomically, that would be a > big win for critical 24/7 systems. > > My approach to this would be an special unionfs with transactional > semantics (I admit: no idea how complex it would be implementing this) A transaction to update multiple files in one atomic go? Nah, this request is for just a single file, although a future extension to multiple files shouldn't be too hard. Olaf -- 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/aanlkti=ur3avv65qfbo+-074fons__8pkq=5zwljm...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o wrote:
> On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>> > Then I invite you to implement it, and start discovering all of the
>> > corner cases for yourself. :-) As I predicted, you're not going to
>> > believe me when I tell you it's too hard.
>>
>> How about you reimplement all of Unix userland, first, so that it
>> doesn't have what you apparently think is a bug!
>
> I think you are forgetting the open source way, which is you scratch
> your own itch.
Most of the time one is writing software because it's useful for
oneselves and others. Not because writing software itself is so much
fun. It's about the result.
So focus should be on what those users need/want.
> The the main programs I use where I'd care about this (e.g., emacs)
> got this right two decades ago; I even remember being around during
> the MIT Project Athena days, almost 25 years ago, when we needed to
> add error checking to the fsync() call because Transarc's AFS didn't
> actually try to send the file you were saving to the file server until
> the fsync() or the close() call, and so if you got an over-quota
> error, it was reflected back at fsync() time, and not at the write()
> system call which was what emacs had been expecting and checking.
> (All of which is POSIX compliant, so the bug was clearly with emacs;
> it was fixed, and we moved on.)
Would you classify the emacs implementation of safe file write
semantics simple or complex?
Why did they not get it right the first time?
IMO it's because the API is hard to use and easy to misuse, while it
should be the other way around.
Hiding behind POSIX semantics is easy but doesn't solve the problem.
> Note that all of the modern file systems (and all of the historical
> ones too, with the exception of ext3) have always had the same
> property. If you care about the data, you use fsync(). If you don't,
> then you can take advantage of the fact that compiles are really,
> really fast. (After all, in the very unlikely case that you crash,
> you can always rebuild, and why should you optimize for an unlikely
> case? And if you have crappy proprietary drivers that cause you to
> crash all the time, then maybe you should rethink using said
> proprietary drivers.)
>
> That's the open source way --- you scratch your own itch. I'm
> perfectly satisifed with the open source tools that I use. Unless you
> think the programmers two decades ago were smarter, and people have
> gotten dumber since then (Are we not men? We are Devo!), it really
> isn't that hard to follow the rules.
I think the number of programmers today is much larger than it was two
decades ago and I also think the average experience of the programmer
went down.
Olaf
--
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/aanlktikj-yl_emcavvls_xn3imrqcpzteavqpey...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 1:54 AM, Ted Ts'o wrote: >> I was thinking, doesn't ext have this kind of dependency tracking already? >> It has to write the inode after writing the data, otherwise the inode >> might point to garbage. > > No, it doesn't. We use journaling, and forced data writeouts, to > ensure consistency. Suppose I append one byte to an existing file, I don't use fsync. Will it commit the inode with the increased size before the data byte is written? In that case, garbage might show up in my file. Olaf -- 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/aanlkti=dw8ks+s3ynw+1-axk3-tsx0ez5g+or5cgv...@mail.gmail.com
Re: Safe File Update (atomic)
On Wed, Jan 5, 2011 at 10:37 PM, Ted Ts'o wrote: >> Ah. So performance isn't the problem, it's just hard too implement. >> Would've been a lot faster if you said that earlier. > > "Too hard to implement" doesn't go far enough. It's also a matter of > near impossibility to add new features later. BSD FFS didn't get > ACL's, extended attributes, and many other features ***years*** after > Linux had them. Complexity is evil; it leads to bugs, makes things > hard to maintain, and it makes it harder to add new features later. That was about soft updates. I'm not sure this is just as complex. I was thinking, doesn't ext have this kind of dependency tracking already? It has to write the inode after writing the data, otherwise the inode might point to garbage. > But hey, if you're so smart, you go ahead and implement them yourself. > You can demonstrate how you can do it better than everyone else. > Otherwise you're just wasting everybody's time. Complex ideas are not > valid ones; or at least they certainly aren't good ones. Nobody said FSs are simple. Olaf -- 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/aanlkti=nxzymkerpue4bai0oe9cn2dcz4=+y1rqio...@mail.gmail.com
Re: Safe File Update (atomic)
On Wed, Jan 5, 2011 at 7:26 PM, Ted Ts'o wrote: > On Wed, Jan 05, 2011 at 12:55:22PM +0100, Olaf van der Spek wrote: >> > If you give me a specific approach, I can tell you why it won't work, >> > or why it won't be accepted by the kernel maintainers (for example, >> > because it involves pouring far too much complexity into the kernel). >> >> Let's consider the temp file workaround, since a lot of existing apps >> use it. A request is to commit the source data before committing the >> rename. Seems quite simple. > > Currently ext4 is initiating writeback on the source file at the time > of the rename. Given performance measurements others (maybe it was > you, I can't remember, and I don't feel like going through the > literally hundreds of messages on this and related threads) have > cited, it seems that btrfs is doing something similar. The problem > with doing a full commit, which means surviving a power failure, is > that you have to request a barrier operation to make sure the data > goes all the way down to the disk platter --- and this is expensive > (on the order of at least 20-30ms, more if you've written a lot to the > disk). > > We have had experience with forcing data writeback (what you call > "commit the source data") before the rename --- ext3 did that. And it > had some very nasty performance problems which showed up very busy > systems where people were doing a lot of different things at the same > time: large background writes from bittorrents and/or DVD ripping, > compiles, web browsing, etc. If you force a large amount of data out > when you do a commit, everything else that tries to write to the file > system at that point stops, and if you have stupid programs (i.e., > firefox trying to do database updates on its UI loop), it can cause > programs to apparently lock up, and users get really upset. I'm not sure why other IO would be affected. Isn't this equivalent to fsync on the source file? It almost sounds like you lock the entire FS during the data writeback, which shouldn't be necessary. > So one of the questions is how much should be penalizing programs that > are doing things right (i.e., using fsync), versus programs which are > doing things wrong (i.e., using rename and trusting to luck). This is > a policy question, for which you might have a different opinion than I > might have on the subject. > > We could also simply force a synchronous data writeback at rename > time, instead of merely starting writeback at the point of the rename. > In the case of a program which has already done an fsync(), the > synchronous data writeback would be a no-op, so that's good in terms > of not penalizing programs which do things right. But the problem > there is that there could be some renames where forcing data writeback > is not needed, and so we would be forcing the performance hit of the > "commit the source data" even when it might not be needed (or wanted) > by the user. > > How often does it happen that someone does a rename on top of an > already-existing file, where the fsync() isn't wanted. Well, I can > think up scenarios, such as where an existing .iso image is corrupted > or needs to be updated, and so the user creates a new one and then > renames it on top of the old .iso image, but then gets surprised when > the rename ends up taking minutes to complete. Is that a common Would this be an example of an atomic non-durable use case? ;) I thought those didn't exist? > occurrence? Probably not, but the case of the system crashing right > after the rename() is someone unusual as well. Given the reports of empty files not that unusual. The delay in this unusual case seems like a small price to pay. > For this reason, I'm cautious about going overboard at forcing commits > on renames; doing this has real performance implications, and it is a > computer science truism that optimizing for the uncommon/failure case > is a bad thing to do. Performance is important, I agree. But you're trading performance for safety here. And on rename, you have to guess the user's intention: just rename or atomic file update. > OK, what about simply deferring the commit of the rename until the > file writeback has naturally completed? The problem with that is > "entangled updates". Suppose there is another file which is written > to the same directory block as the one affected by the rename, and > *that* file is fsync()'ed? Keeping track of all of the data > dependencies is **hard**. See: http://lwn.net/Articles/339337/ Ah. So performance isn't the problem, it's just hard too implement. Would've been a lot faster if you said that ear
Re: devel files and libraries in /lib
On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh wrote: > I doubt it. The symlink doesn't work right now due to the same file > being present on both paths, causing one to be overwritten. Once that > issue is solved, it should not impact upon keeping /usr separate. As > long as a feature such as separate /usr is being used, bugs will get > filed when things break. Let's hope so. What does it take to make this into a release goal? Olaf -- 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/aanlktimglwfut_85xvbvnq6nwxzfqhj-kc9zgs7j9...@mail.gmail.com
Re: devel files and libraries in /lib
On Wed, Jan 5, 2011 at 1:18 PM, Roger Leigh wrote: >> You're right. Is there a project goal for this yet? > > No, that's one of the reasons I've brought it up. > > Practically speaking, this can be done fairly easily. There's no > need to ban having a separate /usr at all. Having /usr as a symlink > to / just needs to be a supported option. This would need: If no separate /usr will be the default, in the long term a separate /usr will probably stop working for the same reason a symlink now isn't possible. Olaf -- 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/aanlkti=yhmtsr4lle1wz1wt1vrbywrzx-c8zxpwqr...@mail.gmail.com
Re: Safe File Update (atomic)
On Wed, Jan 5, 2011 at 1:25 AM, Ted Ts'o wrote: > On Wed, Jan 05, 2011 at 01:05:03AM +0100, Olaf van der Spek wrote: >> >> Why is it that you ignore all my responses to technical questions you asked? >> > > In general, because they are either (a) not well-formed, or (b) you > are asking me to prove a negative. Getting people to believe that you Saying that instead of ignoring half of my response would be more constructive. > If you give me a specific approach, I can tell you why it won't work, > or why it won't be accepted by the kernel maintainers (for example, > because it involves pouring far too much complexity into the kernel). Let's consider the temp file workaround, since a lot of existing apps use it. A request is to commit the source data before committing the rename. Seems quite simple. > But for me to list all possible approaches and tell you why each one > is not going to work? You'll have to pay me before I'm willing to > invest that kind of time. That's not what I asked. Olaf -- 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/aanlktinhnusyvui0jzompde3mkpbuawemy3_-cnpb...@mail.gmail.com
Re: devel files and libraries in /lib
On Wed, Jan 5, 2011 at 1:25 AM, Roger Leigh wrote: > Well, that's the issue at hand. The reason I mentioned this is > because I believe that the / and /usr separation is a case where we > should stop to consider the "bigger picture" rather than just the > immediate problem. Solving that would solve the /usr/lib and /lib > issue as a natural consequence. What about the other stuff in /usr? games, include, local, share, src? > All locations managed by dpkg must be considered a unified whole; it > does not make any sense to share one part and not another. They must > be updated together or else the system will be left in a broken and > inconsistent state. A separate /usr is no longer required to boot the > system now we have initramfs. In consequence, there's no reason to > have /bin separate from /usr/bin, /lib from /usr/lib etc. It makes > sense to have /var separate (writable). It makes no sense to have /usr > separate. You're right. Is there a project goal for this yet? Olaf -- 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/aanlktikdb6dfz5nu7zd2toquvuxuvuqw+6rvayf03...@mail.gmail.com
Re: Safe File Update (atomic)
On Mon, Jan 3, 2011 at 3:43 PM, Ted Ts'o wrote: > On Mon, Jan 03, 2011 at 12:26:29PM +0100, Olaf van der Spek wrote: >> >> Given that the issue has come up before so often, I expected there to >> be a FAQ about it. > > Your asking the question over (and over... and over...) doesn't make > it an FAQ. :-) Hi Ted, Why is it that you ignore all my responses to technical questions you asked? Olaf -- 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/aanlktin0v4sl2zjqkxdekqtuowz3fazkrdbbne=wc...@mail.gmail.com
Re: Source code
On Tue, Jan 4, 2011 at 8:45 PM, brian m. carlson
wrote:
> Because lots of programs expect something like
>
> fd = open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL);
> unlink("/tmp/foo");
> write(fd, "data", 4);
>
> to succeed. This is how Unix filesystem semantics work and pretty much
> always have. POSIX allows unlink(2) to return EBUSY, but that's not at
> all Unixy. The only case I can see for EBUSY is what NetBSD and OpenBSD
> do: restrict unlinking a mount point. (This is also the only case for
> EBUSY on Solaris, Ultrix, and HP-UX.)
unlink will probably return an error, but since that's not checked,
that snippet will succeed.
WRONLY seems weird, what's the purpose of a snippet like this?
Olaf
--
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/aanlktiknvk8a=uukoo2ceogclrcybyuejom+lkp9s...@mail.gmail.com
Re: Safe file update library ready (sort of)
On Tue, Jan 4, 2011 at 7:19 PM, Ian Jackson wrote: > Having said that, I don't think the concept behind your library is > sound, because it presupposes that all previous programs which update > files are buggy. They are. Kinda. They either do unsafe file updates or they have regressions from the unsafe file update case. > Just because some wrongheaded Linux kernel filesystem developers think > that almost all previously written Unix programs are buggy, doesn't > mean that it's true or that the right fix is to rewrite every program. This lib is about making the temp file workaround easier. Olaf -- 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/aanlkti=1hflnzt3gdpqacp5jq_nv28iur-5bfu0ha...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 7:29 PM, Steve Langasek wrote: > On Tue, Jan 04, 2011 at 06:51:13PM +0100, Olaf van der Spek wrote: >> On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim wrote: >> > Maybe we're talking at cross-purposes here; I was speaking about the >> > case of turning a directory into a symlink on upgrades, which cannot >> > safely be done while there are still files under it. > >> > Thinking more about it, this cannot be done even if all packages move >> > their files away from /usr, since an unknown amount of stuff exists >> > under /usr/local, so /usr can ever only be made a symlink to / for new >> > installs (or by the sysadmin). > >> I think it's about /usr/lib being a symlink to /lib. > > No, it isn't. Then what is it about? I thought the problem was having both /lib and /usr/lib. Linking /usr to / would also solve that but is more complex than linking /usr/lib to /lib. Olaf -- 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/aanlktinud2bkmeycecpajgddwvax67ukjpttbjdph...@mail.gmail.com
Re: Source code
On Tue, Jan 4, 2011 at 7:20 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Source code"):
>> Renaming open files works, so that should no longer be a problem.
>
> They have to be able to be deleted.
Why?
Olaf
--
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/aanlktimg-z3yxmvgqozp=w-fvw-scum3stn2gr93g...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 7:13 PM, Samuel Thibault wrote: >> > dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by >> > that enough to make us give up with /usr -> /. >> >> Why couldn't shlibdeps be fixed? > > We kept fixing it, and at some point (where it became really not obvious > to fix it, or would have made it very cpu-consuming to solve the path > ambiguities), we got tired. Got a link to that bug? Seems weird it's unfixable. Olaf -- 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/aanlktimnt8nj4jgbsbgff4p0g3oyjyxf6kium2fgs...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault wrote: > Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit : >> I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really >> unpacks to /lib/libm.so due to /usr -> / symlink, > > dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by > that enough to make us give up with /usr -> /. Why couldn't shlibdeps be fixed? Olaf -- 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/aanlktikxxvbhq6d+f2mo6gr4zdyh8lybphuqc0v0d...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault wrote: > Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit : >> I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really >> unpacks to /lib/libm.so due to /usr -> / symlink, > > dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by > that enough to make us give up with /usr -> /. What's the rationale for getting rid of /usr? Olaf -- 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/aanlkti=8pbwb2b7dgdlhd1gpa=7sf_rqtgtmn_vzu...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim wrote: > Maybe we're talking at cross-purposes here; I was speaking about the > case of turning a directory into a symlink on upgrades, which cannot > safely be done while there are still files under it. > > Thinking more about it, this cannot be done even if all packages move > their files away from /usr, since an unknown amount of stuff exists > under /usr/local, so /usr can ever only be made a symlink to / for new > installs (or by the sysadmin). I think it's about /usr/lib being a symlink to /lib. -- 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/aanlktikemwa0ah_z9-y+erod3odxhubzud7r6eyr5...@mail.gmail.com
Re: Source code
On Tue, Jan 4, 2011 at 3:30 PM, Nikita V. Youshchenko wrote: >> On Mon, Jan 03, 2011 at 04:55:52PM -0800, Don Armstrong wrote: >> > On Tue, 04 Jan 2011, Stephen Grant Brown wrote: >> > > I would like to install dpkg under Windows Vista. >> > >> > This is almost certainly going to be an exercise in pain. >> >> For building it, maybe, but not for getting it prebuilt. Cygwin ports >> has a version: >> (From ftp://sourceware.org/pub/cygwinports/portslist.txt) >> >> dpkg 1.15.7.2-1 > > Some years ago there was an attempt to port Debian to windows kernel. If I > remember correctly, blocking problem was that windows does not allow to > replace opened files, which dpkg deeply depends on. Renaming open files works, so that should no longer be a problem. Olaf -- 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/aanlkti=_jp-wd6mskwuo4pcd0snvk2uy6fusn_zjj...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 2:40 PM, Tollef Fog Heen wrote: > | What about .so files needed before /usr is mounted? > > Do you have a non-contrived example of a .so file which is needed before > /usr is mounted and where there's a need for a static library? Why the second part of that condition? Olaf -- 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/aanlktinvo7fjwd_q5+vwrenoo=htgkngmwq-yu9k3...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen wrote: > | Eh, wouldn't this case be a valid use case? > > No, there's no reason for the .so to live in /lib rather than /usr/lib. What about .so files needed before /usr is mounted? Olaf -- 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/aanlkti=9pdnnqfokecemsoun9fzody91fze70qxf2...@mail.gmail.com
Re: devel files and libraries in /lib
On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen wrote: > ]] Roger Leigh > > | On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote: > > | > I've never used pkgconfig. But if it doesn't support it, it too should be > fixed. > > First, it's pkg-config, and secondly, no, it shouldn't. pkg-config > doesn't try to be everything to everybod and I haven't seen a valid use > case for this. Eh, wouldn't this case be a valid use case? > | An alternative strategy to consider for the future: drop /usr entirely > | and place all libraries in /lib [as done on GNU/Hurd]. On current > | systems using initramfs the need for a separate / and /usr is gone. > | IMHO, there are nowadays few (if any) compelling reasons for having a > | separate /usr, and hence for having /usr at all other than as a > | compatibility symlink to /. Have we actually got any reasons for > | keeping it? > > I'd love to see this happening and would like the ability to have /usr > as a symlink to / as a release goal for squeeze. You mean Squeeze + 1? Olaf -- 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/aanlkti=gywr+qpn-vjawzkz1-f99czoa3-fhd6lfc...@mail.gmail.com
Re: devel files and libraries in /lib
On Mon, Jan 3, 2011 at 8:06 PM, Andreas Metzler wrote: >> What's the problem with fixing automake? > > Hello, > > in a nutshell: I doubt anybody who has the knowledge to fix it cares, > and there is more to it than a > --with-stuff-usually-in-libdir-but-we-want-it-below-urs=/usr/lib. > Installing it there is simple, making use of the installed files is not. > > Have you ever written a pkgconfig file that properly handles the use case > where the static library lives lives in a different directory than the > dynamic one? (And don't limit yourself to directories in the linker > search path.) I've never used pkgconfig. But if it doesn't support it, it too should be fixed. Olaf -- 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/aanlktinja95nt1q6gv0r6tymhhyynep0ppiwnfuuj...@mail.gmail.com
