From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 11:03:07 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD82716A4D1 for ; Mon, 10 Jan 2005 11:03:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9565543D54 for ; Mon, 10 Jan 2005 11:03:07 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0AB37GR095523 for ; Mon, 10 Jan 2005 11:03:07 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0AB35eO095518 for freebsd-rc@freebsd.org; Mon, 10 Jan 2005 11:03:06 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jan 2005 11:03:06 GMT Message-Id: <200501101103.j0AB35eO095518@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 11:03:07 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2004/03/09] kern/63954 rc devfs loses permissions 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/08/29] conf/56144 rc [PATCH] /etc/rc.d/ipmon, /etc/rc.d/ipfilt o [2004/06/30] conf/68525 rc Loader's verbose boot mode has rc.d/local o [2004/07/07] conf/68745 rc /etc/rc.d/devfs runs after ntpd so links 3 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 19:03:58 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B380116A4CE; Mon, 10 Jan 2005 19:03:58 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29B343D45; Mon, 10 Jan 2005 19:03:57 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 474FF1DD496; Mon, 10 Jan 2005 20:03:56 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78372-02; Mon, 10 Jan 2005 20:03:38 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 85C1D1DD4F5; Mon, 10 Jan 2005 20:03:37 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 5D5131C0008A; Mon, 10 Jan 2005 20:03:36 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Mon, 10 Jan 2005 20:03:34 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> In-Reply-To: <1105382156.2497.6.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501102003.35785.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: Eric Anholt cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:03:59 -0000 [rc@ list CCed as this threads on their territory, the start of thread is=20 here:=20 http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] On Monday 10 of January 2005 19:35, Eric Anholt wrote: > On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: > > Jose M Rodriguez escribi=F3: > > > Eric Anholt escribi=F3: > > >> Attached are my proposed patches to deal with the X11 ICE issue. To > > >> review, it's required because having .ICE not owned by root is a > > >> security issue, one that's been papered over with a printed warning > > >> and sleep(5) in libICE for years, and has recently been changed into > > >> an actual error by the X.Org folks. > > > > ... > > > > As a latter think about this, consider take also periodic related fixes > > (We clear this directories by default) and try to get a OS_VERSION bump > > closest to this. > > I'm sorry, I'm not sure what exactly you're talking about here. Are you > saying that /etc/periodic contains something that will wipe out X's > files in /tmp? That would be rather broken. /etc/periodic/daily/110.clean-tmps cleans out empty directories that have n= ot=20 been modified in $daily_clean_tmps_days days. This ones should therefore be= =20 added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to b= e=20 on the safe side. Other than that, I don't really know what would be the best way to handle=20 creation of this directories and haven't commented so far, but since I'm=20 already writing (mostly because I thought rc@ list should be CCed), here's = my=20 opinion FWIW: the simplest seems to be a patch from Pawel Worach at=20 http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445= =2Ehtml The benefit of using this simple approach is that it is simple (of course := )=20 and furthermore it only adds two more directories to /tmp at startup as=20 oposed to adding a file in /etc/rc.d. The difference being one inode. But=20 then again, perhaps I don't see all the implications and this is too simple= =2E=20 Is there a real benefit in creating another rc.d script for doing this and= =20 adding a knob to turn creation of these directories off? Yes of course that would only solve things on -current and -stable, however= =20 there is already an UPDATING entry for this and we can always add a script = to=20 be installed from a port that would take care of transition period (probabl= y=20 as soon in dependency tree as possible, ie -libraries). Dejan From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 19:52:42 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0EA16A4CE; Mon, 10 Jan 2005 19:52:42 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C360543D45; Mon, 10 Jan 2005 19:52:41 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0AJqce1037229; Mon, 10 Jan 2005 20:52:38 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E2DD07.6010607@redesjm.local> Date: Mon, 10 Jan 2005 20:52:39 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <41E23F8F.4040701@redesjm.local> <1105382156.2497.6.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> In-Reply-To: <200501102003.35785.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: Eric Anholt cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:52:43 -0000 Dejan Lesjak escribió: >[rc@ list CCed as this threads on their territory, the start of thread is >here: >http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html] > >On Monday 10 of January 2005 19:35, Eric Anholt wrote: > > >>On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote: >> >> >>>Jose M Rodriguez escribió: >>> >>> >>>>Eric Anholt escribió: >>>> >>>> >>>>>Attached are my proposed patches to deal with the X11 ICE issue. To >>>>>review, it's required because having .ICE not owned by root is a >>>>>security issue, one that's been papered over with a printed warning >>>>>and sleep(5) in libICE for years, and has recently been changed into >>>>>an actual error by the X.Org folks. >>>>> >>>>> >>>... >>> >>>As a latter think about this, consider take also periodic related fixes >>>(We clear this directories by default) and try to get a OS_VERSION bump >>>closest to this. >>> >>> >>I'm sorry, I'm not sure what exactly you're talking about here. Are you >>saying that /etc/periodic contains something that will wipe out X's >>files in /tmp? That would be rather broken. >> >> > >/etc/periodic/daily/110.clean-tmps cleans out empty directories that have not >been modified in $daily_clean_tmps_days days. This ones should therefore be >added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to be >on the safe side. > >Other than that, I don't really know what would be the best way to handle >creation of this directories and haven't commented so far, but since I'm >already writing (mostly because I thought rc@ list should be CCed), here's my >opinion FWIW: the simplest seems to be a patch from Pawel Worach at >http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445.html >The benefit of using this simple approach is that it is simple (of course :) >and furthermore it only adds two more directories to /tmp at startup as >oposed to adding a file in /etc/rc.d. The difference being one inode. But >then again, perhaps I don't see all the implications and this is too simple. > The only I know is that this breaks rcNG writing rules. This is a little more than style. I think that goin more modular can't hurt. >Is there a real benefit in creating another rc.d script for doing this and >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this manner. Why not? >Yes of course that would only solve things on -current and -stable, however > > This was allways the main problem of solve this 'only base'. >there is already an UPDATING entry for this and we can always add a script to >be installed from a port that would take care of transition period (probably >as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps some tweaks to work from ports) installed from Xorg libraries will be the better first step. We may make this install_script conditional when we have the problem solved in RELENG_5 base (test OS_VERSION) and lost this when RELENG_4 life cycle was expired. >Dejan > > > > -- josemi From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 22:37:09 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF03816A4CE; Mon, 10 Jan 2005 22:37:09 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DA5943D5D; Mon, 10 Jan 2005 22:37:09 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0AMb8XC001573; Mon, 10 Jan 2005 14:37:09 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0AMb8YB001572; Mon, 10 Jan 2005 14:37:08 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: freebsd-rc@FreeBSD.org, x11@FreeBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 10 Jan 2005 14:37:08 -0800 Message-Id: <1105396628.866.12.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: more libICE directory creation X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 22:37:09 -0000 (Just found out about this list from lesi@) After several rounds of proposed solutions to the X11 libICE problem, lesi suggested that we just put the .ICE-unix directory creation in cleartmp as was first proposed. Putting a script in ports would be doable, but adds more complications, and we've already got X11 pieces in cleartmp. While preparex11 taking over this job might be cleaner, it's easier to just add it to cleartmp and not make the directory creation optional (it's one inode, which we'd waste just the same by making a preparex11 script). Does anyone have an issue with this? I'm planning on doing it tomorrow unless there's an uproar. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 22:43:37 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD85A16A4D6; Mon, 10 Jan 2005 22:43:37 +0000 (GMT) Received: from rooster.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6125443D5E; Mon, 10 Jan 2005 22:43:37 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from [64.102.192.59] (dhcp-64-102-192-59.cisco.com [64.102.192.59]) by rooster.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j0AMhXe01418; Mon, 10 Jan 2005 17:43:34 -0500 (EST) Message-ID: <41E3051B.4000904@FreeBSD.org> Date: Mon, 10 Jan 2005 17:43:39 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anholt References: <1105396628.866.12.camel@leguin> In-Reply-To: <1105396628.866.12.camel@leguin> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: x11@FreeBSD.org cc: freebsd-rc@FreeBSD.org Subject: Re: more libICE directory creation X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 22:43:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Anholt wrote: | (Just found out about this list from lesi@) | | After several rounds of proposed solutions to the X11 libICE problem, | lesi suggested that we just put the .ICE-unix directory creation in | cleartmp as was first proposed. Putting a script in ports would be | doable, but adds more complications, and we've already got X11 pieces in | cleartmp. While preparex11 taking over this job might be cleaner, it's | easier to just add it to cleartmp and not make the directory creation | optional (it's one inode, which we'd waste just the same by making a | preparex11 script). | | Does anyone have an issue with this? I'm planning on doing it tomorrow | unless there's an uproar. The only issue I have is that this doesn't help -RELEASE users (specifically 5.3-RELEASE users). I suppose this would work if we added it to the errata branch, but for pure -RELEASE users they still won't have a fix. Joe | - -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4wUbb2iPiv4Uz4cRAmlKAJ9i1HIi+oVIWeyXGS3jxhtnISy66ACfYevi /qOid4nxjtqhjeuKPSOFiuU= =0mVL -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Mon Jan 10 23:19:03 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED7616A4CE; Mon, 10 Jan 2005 23:19:03 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4370343D1D; Mon, 10 Jan 2005 23:19:02 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 763501DD430; Tue, 11 Jan 2005 00:19:01 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12250-01; Tue, 11 Jan 2005 00:18:49 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 1FACC1DD45A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 94C5D1C0008A; Tue, 11 Jan 2005 00:18:48 +0100 (CET) From: Dejan Lesjak To: freebsd-x11@freebsd.org Date: Tue, 11 Jan 2005 00:18:47 +0100 User-Agent: KMail/1.7.2 References: <1105396628.866.12.camel@leguin> <41E3051B.4000904@FreeBSD.org> In-Reply-To: <41E3051B.4000904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501110018.47984.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: x11@freebsd.org cc: Eric Anholt cc: Joe Marcus Clarke Subject: Re: more libICE directory creation X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 23:19:03 -0000 On Monday 10 of January 2005 23:43, Joe Marcus Clarke wrote: > Eric Anholt wrote: > | (Just found out about this list from lesi@) > | > | After several rounds of proposed solutions to the X11 libICE problem, > | lesi suggested that we just put the .ICE-unix directory creation in > | cleartmp as was first proposed. Putting a script in ports would be > | doable, but adds more complications, and we've already got X11 pieces in > | cleartmp. While preparex11 taking over this job might be cleaner, it's > | easier to just add it to cleartmp and not make the directory creation > | optional (it's one inode, which we'd waste just the same by making a > | preparex11 script). > | > | Does anyone have an issue with this? I'm planning on doing it tomorrow > | unless there's an uproar. > > The only issue I have is that this doesn't help -RELEASE users > (specifically 5.3-RELEASE users). I suppose this would work if we added > it to the errata branch, but for pure -RELEASE users they still won't > have a fix. > > Joe A short rc script can be added to both -libraries ports (as they are the first in X11 dependencies so we get the script as soon as possible) as a temporary transition workaround. If the __FreeBSD_version is bumped at time when cleartmp is updated, we can install it based on that. And by short I mean something like this: /usr/X11R6/etc/rc.d/000.ICEtmp.sh: -------------------------------------------------------------------------- #!/bin/sh rm -fr /tmp/.ICE-unix mkdir -m 1777 /tmp/.ICE-unix -------------------------------------------------------------------------- Hm, I don't know if that would be OK, but given the shortness of this and that the versions of X.Org/XFree86 in last releases are not so strict about this, this could be put into UPDATING and avoid putting two scripts in ports, but I don't know if this is acceptable. Dejan From owner-freebsd-rc@FreeBSD.ORG Wed Jan 12 17:10:08 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Wed, 12 Jan 2005 17:10:08 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD8B143D31; Wed, 12 Jan 2005 17:10:06 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 70F6D1DD58B; Wed, 12 Jan 2005 18:10:05 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79118-12; Wed, 12 Jan 2005 18:09:48 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id D46961DD476; Wed, 12 Jan 2005 18:09:47 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id EC7631C0071F; Wed, 12 Jan 2005 18:09:46 +0100 (CET) From: Dejan Lesjak To: Jose M Rodriguez Date: Wed, 12 Jan 2005 18:09:45 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> In-Reply-To: <41E2DD07.6010607@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501121809.46129.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: Eric Anholt cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:10:08 -0000 On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > Dejan Lesjak escribi=F3: > >Other than that, I don't really know what would be the best way to handle > >creation of this directories and haven't commented so far, but since I'm > >already writing (mostly because I thought rc@ list should be CCed), here= 's > > my opinion FWIW: the simplest seems to be a patch from Pawel Worach at > > http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/04= 24 > >45.html The benefit of using this simple approach is that it is simple (= of > > course :) and furthermore it only adds two more directories to /tmp at > > startup as oposed to adding a file in /etc/rc.d. The difference being o= ne > > inode. But then again, perhaps I don't see all the implications and this > > is too simple. > > The only I know is that this breaks rcNG writing rules. This is a > little more than style. I think that goin more modular can't hurt. Well it is certainly an exception to how rcNG scripts are otherwise written= ,=20 but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal= =20 of X lock file is already there as that seems the right place to do that.=20 Because of this it also seems natural (to me at least) to just add creation= =20 of another dir there. I believe that having this in this script makes thing= s=20 done at the right time - if one has configured to have /tmp directory clean= ed=20 after boot, then things that should be recreated are recreated right after= =20 that; if no other explicitly ordered cleaning up is done, these directories= =20 (and a lock file) are still "cleaned" away and recreated with side effect o= f=20 having the right permissions. I'm not opposed of going modular, it just see= ms=20 that going modular for the sake of one directory is a bit of an overkill. > >Is there a real benefit in creating another rc.d script for doing this a= nd > >adding a knob to turn creation of these directories off? > > Even more critical paths in the boot process are controlled in this > manner. Why not? As I said, I'm not opposed of doing it in this manner, I just don't see the= =20 real need to create several additional scripts instead of changing two line= s=20 in existing one that already takes care of cleaning (and preparing) /tmp=20 directory. > >Yes of course that would only solve things on -current and -stable, > > however > > This was allways the main problem of solve this 'only base'. > > >there is already an UPDATING entry for this and we can always add a scri= pt > > to be installed from a port that would take care of transition period > > (probably as soon in dependency tree as possible, ie -libraries). > > There are PRs on this. I think that latest rcNG script (with perhaps > some tweaks to work from ports) installed from Xorg libraries will be > the better first step. We may make this install_script conditional when > we have the problem solved in RELENG_5 base (test OS_VERSION) and lost > this when RELENG_4 life cycle was expired. I'm aware of the PRs on this, I wanted to voice my opinion on the particula= r=20 problem of creating a directory /tmp/.ICE-unix with right permissions. Allow me to ramble a bit more on these: If we go to "modular" way as you pu= t=20 it, the we would have to add a script to create ICE-unix directory to, say,= =20 =2Dlibraries ports and a script to remove lock file and X11-unix to -server= =20 ports (more than two of them), while being careful not to let different=20 =2Dserver ports (as in server and nestserver...) step onto each others toes= =2E Or=20 we could make additional port to only install one rc script. This is=20 certainly doable and would of course be more or less modular and could even= =20 have knobs so one could choose if directories should be created/removed and= =20 if lock file should be created/removed. I can't help but to think that this= =20 would be using a bit tooo enormous hammer, that's why I still think a simpl= e=20 solution proposed by Pawel Worach would be enough here. Dejan From owner-freebsd-rc@FreeBSD.ORG Thu Jan 13 02:27:21 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 002B516A4CE; Thu, 13 Jan 2005 02:27:20 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C39E43D2F; Thu, 13 Jan 2005 02:27:19 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0D2RCml008203; Thu, 13 Jan 2005 03:27:13 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E5DC84.60608@redesjm.local> Date: Thu, 13 Jan 2005 03:27:16 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> <200501121809.46129.dejan.lesjak@ijs.si> In-Reply-To: <200501121809.46129.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: Eric Anholt cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 02:27:21 -0000 Dejan Lesjak escribió: >On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > > >>Dejan Lesjak escribió: >> >> >>>Other than that, I don't really know what would be the best way to handle >>>creation of this directories and haven't commented so far, but since I'm >>>already writing (mostly because I thought rc@ list should be CCed), here's >>>my opinion FWIW: the simplest seems to be a patch from Pawel Worach at >>>http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/0424 >>>45.html The benefit of using this simple approach is that it is simple (of >>>course :) and furthermore it only adds two more directories to /tmp at >>>startup as oposed to adding a file in /etc/rc.d. The difference being one >>>inode. But then again, perhaps I don't see all the implications and this >>>is too simple. >>> >>> >>The only I know is that this breaks rcNG writing rules. This is a >>little more than style. I think that goin more modular can't hurt. >> >> > >Well it is certainly an exception to how rcNG scripts are otherwise written, >but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal >of X lock file is already there as that seems the right place to do that. >Because of this it also seems natural (to me at least) to just add creation >of another dir there. I believe that having this in this script makes things >done at the right time - if one has configured to have /tmp directory cleaned >after boot, then things that should be recreated are recreated right after >that; if no other explicitly ordered cleaning up is done, these directories >(and a lock file) are still "cleaned" away and recreated with side effect of >having the right permissions. I'm not opposed of going modular, it just seems >that going modular for the sake of one directory is a bit of an overkill. > > > >>>Is there a real benefit in creating another rc.d script for doing this and >>>adding a knob to turn creation of these directories off? >>> >>> >>Even more critical paths in the boot process are controlled in this >>manner. Why not? >> >> > >As I said, I'm not opposed of doing it in this manner, I just don't see the >real need to create several additional scripts instead of changing two lines >in existing one that already takes care of cleaning (and preparing) /tmp >directory. > > > >>>Yes of course that would only solve things on -current and -stable, >>>however >>> >>> >>This was allways the main problem of solve this 'only base'. >> >> >> >>>there is already an UPDATING entry for this and we can always add a script >>>to be installed from a port that would take care of transition period >>>(probably as soon in dependency tree as possible, ie -libraries). >>> >>> >>There are PRs on this. I think that latest rcNG script (with perhaps >>some tweaks to work from ports) installed from Xorg libraries will be >>the better first step. We may make this install_script conditional when >>we have the problem solved in RELENG_5 base (test OS_VERSION) and lost >>this when RELENG_4 life cycle was expired. >> >> > >I'm aware of the PRs on this, I wanted to voice my opinion on the particular >problem of creating a directory /tmp/.ICE-unix with right permissions. >Allow me to ramble a bit more on these: If we go to "modular" way as you put >it, the we would have to add a script to create ICE-unix directory to, say, >-libraries ports and a script to remove lock file and X11-unix to -server >ports (more than two of them), while being careful not to let different >-server ports (as in server and nestserver...) step onto each others toes. Or >we could make additional port to only install one rc script. This is >certainly doable and would of course be more or less modular and could even >have knobs so one could choose if directories should be created/removed and >if lock file should be created/removed. I can't help but to think that this >would be using a bit tooo enormous hammer, that's why I still think a simple >solution proposed by Pawel Worach would be enough here. > >Dejan > > > > This is really a classic issue. Of course, you may choose, but what you like as a X11 hacker may not be so good for a rc hacker. In this aspect, going modular is more a system eng. need. It's not so direct think that a 'cleartmp' component is so vital for 'x11'. Also, as this is done in cleartmp, you don't have a checkyesno control over the code, as you have in common rcNG scripts. This is exec 'fully inconditional'. What I don't like is add even more params to this without control, but I don't have objetions to maintain the hack with the new needed support. -- josemi