Date: Mon, 2 May 2011 14:12:07 +0200 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Jason Hellenthal <jhell@DataIX.net> Cc: "freebsd-rc@freebsd.org" <freebsd-rc@freebsd.org> Subject: Re: New knob for ignoring readonly fss in 340.noid and 310.locate? Message-ID: <20110502121207.GA31186@curry.mchp.siemens.de> In-Reply-To: <20110502083039.GC6066@DataIX.net> References: <20110430102521.GA11716@curry.mchp.siemens.de> <20110430213157.GC5660@DataIX.net> <20110501081930.GA14448@curry.mchp.siemens.de> <20110502025942.GA31396@DataIX.net> <20110502052739.GB20839@curry.mchp.siemens.de> <20110502083039.GC6066@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 02-May-2011 at 10:30:39 +0200, Jason Hellenthal wrote: > > Andre, Hi Jason, > > Give this a shot. > > http://patches.jhell.googlecode.com/hg/340.noid.patch > > Apply with ( patch -p1 -E < /path/to/340.noid.patch ) > > Then either copy the resulting script to where it needs to go and remove > the old 340.noid or run one of mergemaster or etcupdate. > > This effectively pushes it to periodic/security/310.chknoid which makes > a lot more sense than beeing in weekly as a non-security measure. > > Introduces: > daily_status_security_chknoid_enable="YES" > daily_status_security_chknoid_dirs="" > > By default it populates its directory list with zfs,ufs mountpoints and > will not cross mountpoints as per '-x' options to find(1). Yes, but this won't give me anything in my case. My UFS snapshots will still be found by mount -t ufs,zfs |awk '{print $3}' as we can see here: andre@server:~>mount -t ufs,zfs |awk '{print $3}' / /usr /var /scratch /dump /server /pc /people /share /tmp /people/.snap/@GMT-2011.04.26-03.15.04 /people/.snap/@GMT-2011.04.27-03.15.04 /people/.snap/@GMT-2011.04.28-03.15.03 /people/.snap/@GMT-2011.04.29-03.15.03 /people/.snap/@GMT-2011.04.30-03.15.04 /people/.snap/@GMT-2011.04.23-03.15.01 /people/.snap/@GMT-2011.04.16-03.15.01 /share/.snap/@GMT-2011.04.26-03.28.32 /share/.snap/@GMT-2011.04.27-03.28.26 /share/.snap/@GMT-2011.04.28-03.28.42 /share/.snap/@GMT-2011.04.29-03.29.12 /share/.snap/@GMT-2011.04.30-03.26.48 /share/.snap/@GMT-2011.04.23-03.27.33 /share/.snap/@GMT-2011.04.16-03.27.39 /share/.snap/@GMT-2011.04.09-03.22.01 so I will again have to tweak daily_status_security_chknoid_dirs manually for each machine. While I like your approach, using -x and a list of ufs,zfs instead of the old way of doing it, it doesn't help me ;-). As for the idea of moving it to periodic/security: This might be a good thing but could confuse other who expect this check to be run once a week. Thanks, -Andre > > On Mon, May 02, 2011 at 07:27:39AM +0200, Andre Albsmeier wrote: > >On Mon, 02-May-2011 at 04:59:42 +0200, Jason Hellenthal wrote: > >> > >> Andre, > >> > >> > >> On Sun, May 01, 2011 at 10:19:30AM +0200, Andre Albsmeier wrote: > >> >On Sat, 30-Apr-2011 at 23:31:57 +0200, Jason Hellenthal wrote: > >> >> > >> >> By default snapshots directories are hidden and treated as a virtual > >> > > >> >Is it possible to hide snapshots directories in UFS? > >> > > >> > >> Snapshot directories on UFS are treated differently than they are in > >> ZFS. UFS snapshot directories live as the base of the filesystem and are > >> not auto-mounted perse when you cd(1) into them so therefore there isn't a > >> need to hide them because they cannot be traversed. > > > >They are mounted and they have to be mounted (at least here). If > >they weren't mounted, people couldn't access them. That's why > >they are also being traversed by 310.locate and 340.noid. To > >summarise: > > > >- I use UFS. > >- My snapshots must be mounted. > >- They are being traversed by 310.locate and 340.noid. > >- I don't want the latter. > > > >To accomplish this, I can play around with (directory name dependent) > >exclusion lists for 310.locate and 340.noid. I could also implement > >a rdonly knob. > > > > -Andre > > -- > > Regards, (jhell) > Jason Hellenthal > -- Note: No Micro$oft programs were used in the creation or distribution of this message. If you are using a Micro$oft program to view or forward this message, be forewarned that I am not responsible for any harm you may encounter as a result.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110502121207.GA31186>