Re: Reading rc.conf from C programs?
On Thu 2003-01-02 (13:52), Jordan K Hubbard wrote:
> In hindsight, if we'd really wanted a key/value pair database then we
> should have done it in XML and simply dealt with it at arm's length
> through a accessor utility, e.g. instead of:
>
> case ${ipsec_enable} in
>
> We'd have:
>
>case `sysconfig -r ipsec_enable` in
>
> Or something to that effect.
>
> If you're really looking for "the real solution" underlying this
> problem then you need to look past the format being used at the moment
> and at the fundamental problem it was originally trying to solve.
Hi Jordan,
I'd probably rather have a program to export the whole configuration
into the environment, but obviously this does mean there's no dynamic
query. Dynamic query might be nice, since it would start using, for
example, network configuration once it is available.
I've proposed before that we have an sh script that can be sourced and
it'll magically do whatever is necessary to put the configuration into
the environment - ideally there'd be a C library that'd do the same.
Although it's ugly to look at (since 'ed' is the only text manipulation
available), I show in
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=68185+0+archive/2002/freebsd-arch/20020414.freebsd-arch
how we can take the output of any given command ("backend") that is in
the 'foo="blah"' format and export it into the shell environment.
So, if we had a "/etc/rc.backend" that is either symlinked to or
executes the backend (say, "sysconfig -a"), then we can dynamically
generate the configuration from over the network (assuming we've managed
to get that set up) using LDAP or netinfo. Possibly, libsysconfig would
provide the same functionality for C programs, similar to PAM or
nsswitch.
Actually, for me it doesn't matter, so long as we actually get over the
hurdle of not being able to read/edit the configuration automatically.
If we'd done it when I originally suggested it in 2000, we'd have tons
of excellent tools like thefish already.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: key=value in rc.conf (was Re: Reading rc.conf from C programs?)
On Fri 2003-01-03 (14:11), Andrew wrote: > > They're in the CVS repository. Do a "cvs diff -c" before and after > > the code was added to the file, and you'll get my diffs. 8-). > > Perhaps the stuff at the bottom of defaults/rc.conf needs to be in a > seperate file (like read_rc_conf.sh) with another line or 2 to read in > defaults/rc.conf first. > > That way shell scripts needing to parse rc.conf call upon a tool to do it > in the same way as C programs are having to. From that point on rc.conf > can be key=value pairs only. > > Would this solve everyones problems or am I overlookign something? > with "unsubscribe freebsd-hackers" in the body of the message I've proposed this before (in January 2000), including code to replace all the 'sh' usages of it. Didn't write the tokeniser for C, though. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=48338+0+archive/2000/freebsd-hackers/20001008.freebsd-hackers I got one "go ahead", but a "I don't see the point" from the then-pseudo-maintainer of the rc stuff. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestion: usbd.conf uses rc.conf for options
On Mon 2002-10-28 (13:57), Peter Pentchev wrote: > This had better be ". /etc/defaults/rc.conf; source_rc_confs; ..." :) > > I have been thinking for quite some time of writing a little utility > that parses various configuration file mechanisms and allows the > administrator to specify which config mechanism to use for which > program. I have a simple design in mind, which would allow direct > variable setting, use of /etc/rc.conf, use of other configuration files, > use of daemontools-style envdirs, and a couple of others, but so far, > there has been no time to actually start writing a simple > proof-of-concept thing. Funny now, the timing; I was thinking of > writing up a simple rcenv(1) today or tomorrow, and then I saw this > thread :) Go for it (please!). Check out: Subject: non-variables in rc.conf (Re: proposed code: automatic setting of hostname from MAC address) Message-ID: <[EMAIL PROTECTED]> On arch mailing list: <<<=== Abstracting the configuration away from "shell scripts and functions" would allow us to pull the configuration in from other locations in the "backend". The one basic example I did perform was in the order of (replace \ns with real enters): eval `echo 'g/^[:space:]*$/d\ng/^#/d\ng/$/s//;/\ng/./' | ed -s \!'cat /etc/rc.alternate.conf'` Anyway, assume that we can get our network configured beforehand, and we can then use ldap, NIS, or whatever (netinfo?) to get our configuration. ===>>> When we can finally get rid of non-variables in the configuration system we no longer rely on 'sh', and we can read configuration using any programming language, and/or (even better) back the configuration up with LDAP or whatever. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat 2002-06-22 (00:06), Chris Dillon wrote: > Yes, but this is the case with any IMAP server and doesn't really have > anything to do with Cyrus in particular. Unlike other IMAP servers, > however, Cyrus supports SASL which offers plenty of non-plain-text > authentication options, unfortunately none of which work with a local > FreeBSD password database that I know of. Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). > There is always the option > to use SSL, which is my preference, but unfortunately neither SSL nor > SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... Which IMAP clients don't? Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue 2002-04-23 (21:13), Joerg Micheel wrote: > On Tue, Apr 23, 2002 at 06:34:52PM +0930, Greg 'groggy' Lehey wrote: > > Well, yes. But I've been using X for 11 years. Why should I have to > > read the man page to find changes? How do I know which man page to > > read? If I did that for everything that happened, I wouldn't get any > > work done. And you can bet your bottom dollar that somebody coming > > from another UNIX variant and trying out FreeBSD won't do so. They'll > > just say that it's broken and wander off again. > > FWIW, I would be extremly pissed about this myself, I just happen to > not having installed 4.5 myself yet, for other reasons. I thought there > was a policy of the least surprise, it might have been to kernel code, > but should be applied here as well. > > The system has to work right away, when installed out of the box. Period. > No when's and if's. And don't tell me that X11 is an add-on and luxury. > We are living in the 21st century. There are people who will tell people that still use X11 tcp sockets to start living in the 21st century. ssh X11 forwarding still works, it's only the (often much lower security) tcp sockets that are disabled by default. (And if the "none" cipher is available, the overhead would be minimal for even the most underpowered machine.) At least Debian takes this stance, and so many believe it's a sane default. If it were reverted, I'm sure there'll be lots of people re-adding the change to their security regimen. And lots more people scurrying to patch when the next DoS or exploit comes out. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about what programs to use in /etc/rc*
On Sun 2001-09-09 (13:38), Ulf Zimmermann wrote:
> On Sun, Sep 09, 2001 at 01:11:52PM -0500, Alfred Perlstein wrote:
> > * Ulf Zimmermann <[EMAIL PROTECTED]> [010909 04:47] wrote:
> > > Hello everyone.
> > >
> > > I am looking at some PRs and I am trying to come up with a solution to
> > > submit a patch. I know how to use expr to test as tring in sh inside
> > > of a /etc/rc* script, but what method would people recommend to remove
> > > part of the string after expr confirmed that something is part of it ?
> > >
> > > These are some examples strings:
> > >
> > > "dhcp"
> > > "dhcp media 10baseTX"
> > > "media 10baseTX dhcp mediaopt half-duplex"
> > >
> > > The following code will get me inside a if condition:
> > >
> > > if [ `expr "${ifconfig_args}" : '.*[Dd][Hh][Cc][Pp].*'` -ne 0 ]; then
> > >
> > >
> > >
> > > fi
> > >
> > > What I would like to do inside the if .. fi is to remove "[Dd][Hh][Cc][Pp]"
> > > from the string so that the rest of the options can be used to call ifconfig.
> > > Otherwise the if .. fi will test if the string is then empty or just white
> > > spaces and if so it will not do anything but set ${dhcp_interfaces}. If its
> > > not empty it will call ifconfig with the extra options to set the interface.
> > >
> > > Awk/sed comes to mind but those are in /usr/bin and I am trying to avoid
> > > that.
> > >
> > > Any suggestions from the more experienced hackers ?
> >
> > sed? :)
> >
> > sed 's/[Dd][Hh][Cc][Pp]//g'
> >
> > -Alfred
>
> sed is in /usr/bin and so its not a too good idea to use it in a /etc/rc
> script. There is sed also in /stand, can that be used ?
Nope, you can't. However, you might be able to do it all within sh, by
using case and "Parameter Expansion" (see the section in the sh man
page).
Try this:
case ${ifconfig_args} in
*[Dd][Hh][Cc][Pp]*)
# do stuff with whatever
$ifconfig_args=${ifconfig_args%dhcp}
;;
esac
This probably won't work, since I've not tested it. Casedness is
irritating too - dd.sh would advocate converting it all to lowercase
with ``dd conv=lcase''. ;)
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: getting rid of sysinstall - Was: FreeBSD Mall now BSDCentral
On Wed 2001-07-11 (19:02), Karsten W. Rohrbach wrote: > Terry Lambert([EMAIL PROTECTED])@2001.07.09 13:29:23 +: > [...] > > > There are too many steps. > > > > X11 is a distribution set, instead of a package. > > > > Etc. (I could go on forever). > > > > ...then let's wrap up a concept of a interpreter language driven > installer. redhat does it in python since years, so could we... > > some rough and spontaneuos ideas: > - stripped down python interpreter runs as init > - class framework for 'plugin modules' such as postinst config,... > - basic 'service' classes for abstraction of the ui, binary execution > and fileio (for config files) ... > so the scheme would boil down to something like this: > > [gui multiplexer]<--+-->[cli] > ^ +-->[text ui] > [cdboot/loader] | +-->[xf86 gui] > | | +-->[remote ui] > v | +-->[unattended] > [kernel]->[python]->[rc-loader] | > | | > v v > [messaging/core]<--+-->[config writers] > ^ +-->[exec subsystem] > | |^ > v || > [sig verifier]<->[dist source handling] |v > ^ | [fdisk/disklabel/...] > [cd mount]<-+ | > [hd mount]<-+ +-->[upgrade subsys] >[nfs mount]<-++-->[package installer] > [ftp/http fetcher]<-+ > > > this in no way perfect, just some idea -- feel free to flame me if i > missed the point, but don't rip out my intestines ;-) > s/python/tcl/, and you're talking about "libh". Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
On Wed 2001-05-23 (22:08), Jacques A. Vidrine wrote: > On Wed, May 23, 2001 at 08:10:20PM -0400, James Howard wrote: > > I am missing something here. Is there a practical use for this? :) > > You are not the only one. I can appreciate the `neat' factor, but I > cringed at the commit. It seems like functionality that would be > better put in a separate utility (or port even). It's not like you'd > ever want to run the NVT protocol over an AF_UNIX socket. I'm currently using pppctl for this function, in the absence of anything else in base that can do this. To good effect, I might add. ;) Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH Must Die
On Sat 2001-05-12 (04:24), Terry Lambert wrote: > This whole ssh B.S. is very annoying. > > After an upgrade from 4.2 to 4.3 using a CDROM boot plus > upgrade menu option, SSH stops working, for no good reason > (_any_ reason is no good). > > It complains about RSA not being in libcrypto, even though > "nm" shows that that claim is full of crap. > > Yes, I have /dev/random, and yes, I have it in my kernel, > even though it makes my boots slow as hell. 4.3 doesn't have "device random", or any way of building without it. How is it changing the speed of your boot? I've actually just done a 4.3 CD upgrade, but not from 4.2, and it worked. Can you give the modification times of your libcrypto and ssh, and make sure you're executing /usr/bin/ssh. And the output of 'ld /usr/bin/ssh'. Perhaps truss an ssh to a host and disconnect immediately. It might be failing after trying to open or read from /dev/urandom. Can you give the output of 'ls -l /dev/*random'? Maybe someone will have something useful to go on from the information above instead of "it doesn't work". Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Jail Pseudo Terminals
On Tue 2001-02-13 (07:09), Lists Account wrote:
> Ok this is getting a bit strange. Interestingly enough ssh works 100%
> with my method of tty creation, having created (from outside the
> jail) ttyp32 - ttyp100 (with the minor/major numbers set as 5,XX where XX
> is ttypXX), and a mknod type of c, ssh allocates ttys fine, however screen
> still tells me there are no ttys available?
>
> Any ideas?
Recompile screen with the extra devices present - it uses some really
interesting system to work out what devices to use, and it will limit
you to ttyp*, and not tty{q,r,s,P,Q,R,S}*, if the latter aren't
present.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > All, > > I've committed these changes for cron to support DST change > to -current (see PR bin/24494 for description of my tests). > Everyone is welcome to test them out. > Please let me know if you encounter any problems caused by them > (and better do that before these changes would be MFCed to -stable > in a few weeks). I do believe this is premature. There really should at least be an option for the old behaviour, and there is a good argument for making the new behaviour optional dependent on a variable with the old behaviour default. _Especially_ if you intend to MFC this, since changing this behaviour in a minor release, without a way to have the old behaviour, is almost certainly wrong. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Fri 2001-01-19 (12:44), Matt Dillon wrote:
> :I'm just editing the PR with the cron patches to "catch up" with
> :OpenBSD in this respect (stating that it doesn't handle DST, but
> :has benefits whenever one's clock is jumping or cron waking up
> :too late and _could_ be extended to handle DST). Therein I
> :suggest to
> :- not touch current cron at all but switch to a different
> : executable by means of the newly introduced rc.conf variables
> : or to
> :- modify cron but make the new code optional while defaulting to
> : off
> :(in this order). Although I cannot say which variant will happen
> :driven by those with enough priviledges to decide and commit. As
> :well as I cannot even tell you if something will be done at all
> :in the near future regarding the fact that there's no DST
> :solution available yet -- which was the actual reason for the
> :wish to change something.
> :
> :virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
> :Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
>
> In the second suggestion, I presume turned off by default
> but can be turned on with a command-line option? (Verses
> a make.conf compile-time variable). I like the idea of
> a command-line option to turn on the 'new' code. That provides
> a consistent, straightforward way of allowing developers to test
> the code, making it available in releases with a simple rc.conf
> twitch, and eventually (years later judging by the flame war:-))
> turning it on in /etc/defaults/rc.conf.
There seems not to be a real argument against the algorithm, plenty of
support for having it available as an option, and only an argument
against it being default. I'm quite happy for it not to be default, as
I'm sure Gerhard is.
Thus, there's no reason not to add the ability (at least OpenBSD, Debian
and HP-UX have similar behaviour), so we should proceed. All we need do
is add the option to getopt, and turn the "optimisation check for the
default 1 minute case" to check if the "new behaviour flag" is not
checked. Ie:
if (!bflag || (timeDiff == 1)) {
virtualTime = timeRunning;
find_jobs(virtualTime, &database, TRUE, TRUE);
} else {
wakeupKind = -1;
if (timeDiff > -(3*MINUTE_COUNT))
wakeupKind = 0;
...
It should work exactly like the old cron behaviour, unless the '-b' flag
is given.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix "make buildkernel requires full obj directory" mistake
On Thu 2001-01-18 (20:13), Warner Losh wrote: > In message <[EMAIL PROTECTED]> Josef Karthauser writes: > : On Thu, Jan 18, 2001 at 05:36:30PM -0700, Warner Losh wrote: > : > In message <[EMAIL PROTECTED]> Josef Karthauser writes: > : > : Hear hear. We had to back out the 'make buildkernel' within PicoBSD > : > : because there was no guarentee that the user had ever done a make > : > : buildworld. Additionally if you do an > : > : env MAKEOBJDIRPREFIX=/usr/myobj make buildkernel > : > : you have the same problem even if someone did do a make buildworld. > : > > : > Wait a minute. I thought that crunchgen required a buildworld... > : > : In no way at all what do you mean? > > I thought that crunchgen dealt with the .o's that were created in the > buildworld process. It looks like it rebuilds them itself in a > whacked out way to make the whole thing work. > > Still, I don't think it is too onerous a requirement that a buildworld > have happened first. The problem then is that the programs aren't built with the correct set of defines and environment. This prevents a forth-less loader, YP-less libc, and so forth. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Patch to fix "make buildkernel requires full obj directory" mistake
Hi,
I've kept on forgetting to apply a patch similar to this one.
"make buildkernel" currently fails if a "make buildworld" has not
previously been done on the machine (and still has the populated object
environment) because OBJFORMAT_PATH is explicitly set to only use
${WORLDTMP}/usr/libexec. At least for the kernel build phase, this may
be an error, since we already use 'gcc', 'ld', and friends from $PATH.
Anyway, the attached patch fixes at least buildkernel in the way most
obvious to me, but I'm sure there may be a more useful place to place
the addition of OBJFORMAT_PATH, since $PATH is made to include the
supplied $PATH environment variable in many other places. I'm not
willing to make a judgement whether using the supplied OBJFORMAT_PATH is
correct in any of those places, but I wish to fix the buildkernel
target.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.180
diff -u -r1.180 Makefile.inc1
--- Makefile.inc1 2000/12/24 14:58:34 1.180
+++ Makefile.inc1 2001/01/18 08:03:08
@@ -129,6 +129,7 @@
# /usr/games added for fortune which depend on strfile
STRICTTMPPATH= ${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games
TMPPATH= ${STRICTTMPPATH}:${PATH}
+OBJFORMAT_PATH?= /usr/libexec
TMPDIR?= /tmp
TMPPID!= echo
@@ -200,6 +201,10 @@
PATH=${STRICTTMPPATH}:${INSTALLTMP}
IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
+# kernel stage
+KMAKEENV= ${WMAKEENV} \
+ OBJFORMAT_PATH=${WORLDTMP}/usr/libexec:${OBJFORMAT_PATH}
+
USRDIRS= usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \
usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc
@@ -408,10 +413,10 @@
${MAKE} -f ${KRNLSRCDIR}/dev/aic7xxx/aicasm/Makefile
.if !defined(NO_KERNELDEPEND)
cd ${KRNLOBJDIR}/${_kernel}; \
- ${WMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} depend
+ ${KMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} depend
.endif
cd ${KRNLOBJDIR}/${_kernel}; \
- ${WMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} all
+ ${KMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} all
.endfor
#
Re: Permissions on crontab..
On Wed 2001-01-17 (20:43), Michael Bacarella wrote: > On Thu, Jan 18, 2001 at 01:07:35AM +, void wrote: > > > > True - but I'd say it provides a false sense of security, which > > > might be more damaging than the extra security provided against > > > read-only exploits in crontab. > > > > That's silly. Group tty can be leveraged to provide more privilege, > > but that doesn't mean write(1) should be setuid root, or that having > > write(1) setgid tty provides a false sense of security. > > > > I think that the proposed change would be a good idea, and that it's > > consistent with write(1) and other uses of setgid. > > Ideally, crontab wouldn't be suid/gid _anything_ and users own their > own crontab file, but perhaps I've said too much. :) They do own their own crontab file. The setgid is for adjusting the modification time on the crontab directory, to signal to cron that there has been a change. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
On Wed 2001-01-17 (17:04), Greg Black wrote:
> > In the last episode (Jan 17), Greg Black said:
> > > Michael Bacarella wrote:
> > > > Why is crontab suid root?
> > > >
> > > > I say to myself "To update /var/cron/tabs/ and to signal cron".
> > > >
> > > > Could crontab run suid 'cron'?
> > > >
> > > > If those are the only two things it needs to do, run cron as gid
> > > > 'cron' and make /var/cron/tabs/ group writable by 'cron'.
> > >
> > > It has to run jobs as the correct user and must be able to setuid
> > > accordingly.
> >
> > Not quite. As far as I can tell, crontab is setuid root for the sole
> > purpose of being able to write to /var/cron/tabs. Cron checks the
> > timestamp on the directory every minute, so crontab doesn't have to
> > signal it for changes to get noticed.
>
> > If you're paranoid, you can
> > probably "chgrp cron /var/cron/tabs" and make crontab setgid cron
> > without any ill effects. Cron itself must stay setuid root, of course,
> > so it can run user crontabs as that user.
>
> Dropping the setuid bit on crontab in favour of a setgid cron
> alternative also means changing the permissions on the
> /var/cron/tabs directory which is currently only accessible to
> root. I'm not sure I would want anybody else to have access
> there. But it would probably work OK.
You need only add group read and write permissions for the crontab
group. Since noone is in the crontab group, unless they invoke crontab,
noone will be gaining any "extra" privilege. I also toyed with making
the directory sticky, and adding sanity checks to cron to not invoke
tabs not owned by the user they refer to or root, or at least give
warnings.
FWIW, I had patches to convert 'at' and 'crontab' to being sgid-at
and sgid-crontab ('at' has some really ugly macros that luckily aren't
needed again). I'll probably be doing them again, now that my time is
more sane.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Hi, > And, as I said previously, I'd want to know how the new code > coped with cron being stopped and restarted during one of the > DST transition times, as well as seeing assurances that the > legacy version would do the same thing then as it does now. The legacy version only checks for jobs that fire in the exact current minute. If it was stopped, it wouldn't run jobs for the missed time. The new behaviour is to run the fixed-time jobs that are between the last known time, and the current time, if the stop time is less than 3 hours (if it is more, assume that the change is not a standard DST thing or normal corrective time change). If the time change is less than 5 minutes, then cron should try run all jobs for each minute that passed between the last known time and the current time. If over 5 minutes, then cron will check for all wildcard jobs that would have fired, and run it only once, even if it would have run multiple times). If time goes backwards, fixed-time jobs are assumed to have already run, and if we happen to match a wildcard job for the current minute, run it. If there is a fixed job at 2:40, and we pass 2:40, run the job, and then at 3, time goes backwards, don't run it. If cron gets killed at 2:50, and started at 2:55, and time goes backwards to 2:00, the 2:40 job isn't run either, since the virtual time is still at 3:00. If cron is running at 2:40, the job is run, cron is killed, and restarted just after the change back to 2:00, it will run the 2:40 job, as it wasn't around to experience the DST change. Similarly, if cron isn't around to experience a forward jump, it won't magically know to run the jobs missed. All of which makes me ponder putting cron_tz option in rc.conf and suggesting people set it to UTC or some other non-DST-afflicted place, but that isn't the only use of these changes. However, the new behaviour does do the expected things for common changes - if it's a relatively small forward jump, run whatever jobs would have run. If it's a medium-sized jump, run all the fixed-time jobs, and one of each wildcard job that would have occured. If it's a massive jump, assume something unusual is up, and don't run any jobs. If it's a small backwards jump, assume fixed-time jobs shouldn't be run again until we reach the time we jumped back. And if it's a big backwards jump, assume something unusual is up, and just start functioning as if the time hadn't changed. The previous behaviour says not to care what changes occur in time whatsoever, and only compare this exact current minute of the waking up to the crontab list, and run those jobs. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (12:52), Doug Barton wrote: > > To summarise: It is broken, > > According to your definition of broken, which we have not > necessarily reached a consensus on. I agree - there is no consensus, and there never will be. Some people want cron to be reliable, and not skip jobs or run jobs multiple times, and other people want cron to be reliable, and to skip jobs and run jobs multiple times. I believe the reliable behaviour is to never skip jobs. People schedule fixed-time jobs (the _only_ type affected by this change) with the intention that they will be run. I also believe people schedule fixed-time jobs (tagain, the only type affected by this change), with the anticipation that it will be run only once. Time doesn't really go backwards or forwards merely due to timezone changes or corrective time changing. Wildcard jobs are not affected by this change. Your hourly jobs will run every hour still. _Every_ hour. If there are two two-o'clocks in a row, it will be run twice, because in reality, there has been an hour passing. Every five minutes will run every five minutes, even if you correct the time backwards 18 minutes - it'll run at 10:30, 10:15, 10:20, 10:25, and 10:30 again (just like the current cron behaviour). One side says POLA means never changing a programs, and others say POLA means that a program shouldn't act in an astonishing way. They both have merit. > > Not only that, but people who don't understand that it is broken are > > unable to understand simple facts. > > Or perhaps we understand the simple facts, but there are more > complex facts that make this change a bad idea. Note, I was quoting a detractor, not saying this myself to anyone. I don't attack people when I don't agree with their argument. > > In addition, it took the FreeBSD > > project about 7 years to finally get their daily runs to run exactly > > once, once every day. > > This is overstating the case. It was never really considered a > huge issue by most, and at various times in the past the "correct" change > for the majority of our userbase got mired down in socio-political > arguments that had nothing to do with the technical merits. Of course it's hyperbole - what I'm saying is that every 6 months people get confused (and astonished) that jobs get skipped or doubled, and still nobody could agree on a simple way to fix this. My personal concern isn't DST changes (since I'm not influenced by them), but other corrective time measures that cron really should act reliably around. > > What we haven't seen is any technical opposition to the algorithm used, > > which has been explained. > > What you are seeing is opposition to the idea itself. I'm not > going to waste time analyzing the implementation of what I think is a bad > idea. :) The opposition I've summarised already: "People who don't know that cron is not reliable are unable to understand basic facts" (rough paraphrase). The arguments have often been against the idea in it's entirety, saying that this behaviour should never occur, even as an option, since it's a stupid idea. That is policy, and should be ignored - we don't enforce policy on our users. The only argument people can have is against the implementation of the change, and whether it should be default or an option. The implementation is good, unless someone cares to review it. I think it should be default, as the only people who will be inconvenienced by the new behaviour will be people who already consider cron to not be reliable around time changes. If they rely on it being unreliable, they can always use an option supplied to get the old behaviour, since they already spend a lot of time thinking of how to avoid the problems inherent in the old behaviour, and remembering a command line option (or looking it up in the man page) shouldn't be an issue for them. Yes, this is a POLA issue - it is astonishing to people that cron behaves this way, when they first see it. It will be "astonishing" to very fewer people if the default changes to the new behaviour, and we accomodate these people by placing it in the release notes, having an option for the old behaviour, and possibly delaying the use of the new system in the -STABLE branch until 5.0, if that is deemed necessary. Now, if anyone has a reasoned argument about the new algorithm (like, how it handles certain kinds of events in a surprising way), I'd like to hear it, or we can proceed to make it an option. If anyone has some clear cases why this is a truly astonishing change for people that can't adequately be handled in the accomodations listed above, we can hear your concerns too. If there is no clear winner, we can have it as just an option. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
of them agree (33% haven't expressed an opinion) without provocation that those people with major skills will read the release notes. Common sense indicates that they are able to use a command line option that disable the new reliable behaviour. There has been expressed a need for testing. That is dealt with by three years in OpenBSD, and a period of time in the development branch, as per most development. What we haven't seen is any technical opposition to the algorithm used, which has been explained. If there is a problem with it, then that should be determined. My review of it indicates the OpenBSD cron behaviour is very specific, reliable, and obvious. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (22:35), Dan Langille wrote: > That's a relatively smaller user-base compared to FreeBSD. Do you > consider that sufficient? I would, yes, considering it has been three years. You may feel free to disagree, of course, and I'll get to why next: > I don't see how the above relates to my point about sufficient testing. It > seems to be a repeat of what you've said before. I obviously agree sufficient testing is required. Luckily, we have -CURRENT for "sufficient testing". If it's an incredible concern, this change could be postponed to being in a release until 5.0; by then we'd have had our own testing for at least one DST change, and OpenBSD's testing for at least 7. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (21:20), Dan Langille wrote:
> > > And when you finally realize that everyone else thinks this is a great
> > > idea,
>
> I do not like being included in "everyone". I don't think it's a great idea.
If you didn't miss the comment, I was (and am now) attempting to emulate
Doug's style. (The "I don't like this change, and since nobody
commented, it must be a terrible thing" style.)
> > In fact, I'm quite sure that this is not true. I happen to be the only one
> > who is currently voicing opposition.
>
> IMHO, the solution is not to schedule jobs during during the changeover
> period. However, *if* the mods are adopted, it should default to off. Add
> a switch to turn them on. See how that runs for a few years. Then, and
> only then, if the feedback is positive, consider changing it to the default
> behaviour. Such a radical change to cron cannot be implemented
> without sufficient field testing. That will take years. It cannot be
> simulated.
These changes have been tested in OpenBSD for 3 years. The "solution"
is _not_ to tell people they're stupid to schedule jobs during the
changeover. It has nothing to do with them. If they want jobs at 2am
in the morning, that's cool. The fact the changeover is a problem is
cron-specific. It shouldn't be trying to be clever and work with local
time when local time does weird things like randomly add and remove time
from existence. However, since it _does_ have this "feature", we should
accomodate people who are negatively affected by it. It _will_ fix the
twice-yearly complaint about extra and missing jobs. It may create
unexpected behaviour for a tiny percentage. Those people should be
reading the release notes ("or they shouldn't be system administrators
or run FreeBSD").
Again, this change is from OpenBSD. We will synchronise with their
changes, and perhaps offer them back a patch to ignore what "ultra leet
sysadmins who rely on broken behaviour because people who don't are
simply stupid and shouldn't be running FreeBSD anyway!" with an option.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed 2001-01-10 (08:51), Greg Black wrote: > If any change to expected cron behaviour is to be introduced, > the traditional behaviour must be the default, with a knob > documented in the man pages that can be twisted to get the > oddball behaviour that is being proposed here. The oddball behaviour that is what, I imagine, the vast majority of people expect. We could take a vote here, if you like. Are you at all deluded into believing your position would win? I'm sorry, but cron should never miss jobs. And it should preferably not run the same job twice. All the hacks we've had to go through to simply get our daily jobs to run reliably (yes, this "reliable" word again). This oddball behaviour, unlike the numerous hacks tried before, and which still don't solve the intrinsic problem, has been tested, and is default, on OpenBSD, for the past 3 years. My reading of the code seems to indicate it does the right thing in all time update cases - it doesn't repeat wildcard jobs multiple times for the "medium" jump (1 to 3 hours), it doesn't miss jobs for any size jump forward, and it doesn't repeat jobs for negative jumps. It just ignores insanely big jumps (ie, over 3 hours). Since this is the default in OpenBSD, and we want to not randomly diverge from their code, and since they're more likely to accept code to ignore DST changes that a couple of people thinks is the correct thing, and so forth, we should have the behaviour as default. (Not to mention that it'll solve the endless complaints about missed or repeated runs we get twice every year. And no, these aren't clueless administrators as you and Doug believe, but people who expect tools to be reliable and do the obvious thing. Also, the only reason cron is doing the wrong thing now is that it is trying to be clever to let people set jobs in their local time, and we get bit because of silly things like DST. It should, of course, be expressed as UTC.) Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
hat you're proposing is a bad idea.
> Do all the testing you want, but make sure you understand that there
> will be vigorous resistance to incorporating your proposed changes.
And when you finally realize that everyone else thinks this is a great
idea, you'll stop your sole campaign to vigourously resist the
incorporation of this code? If it helps, we can have an option ('-i')
to ignore DST changes, for "advanced administrators who know what
they're doing and expect jobs to be lost or run multiple times depending
on exactly when they schedule their jobs", and the "clueless newbies who
ignorantly expect a job scheduled at 2am to not only run, but run only
once" can be served too, by default.
(Attitude almost entirely feigned to match Doug's)
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: RFC: a CUI controlpanel for FreeBSD
On Thu 2001-01-04 (23:13), AGX wrote: > I firstly developed everything using cdialog but them are very buggy > togheter with somebody i did developed "libgringo" that is a generic > library that interface both ncurses and Gtk (depending how you > compiled it) and allow you to write script that can run both in console > both in X-Window. Where can I look at this stuff? What scripting language do you use when you say 'write scripts'? > I would like to know if you think that is usefull or not to do this > job or if there are more urgents work to do upon the FreeBSD distribution/ > installation process. I've wasted 4 years trying to create my personalized > GNU/Linux distribution and i'm tired of to remake each time the same job. There're lots of things you can do on FreeBSD, but it's generally best to do the stuff you most enjoy and/or are best at. If you like writing documentation, there's the documentation project; if you like general hacking, generally hack, and if you like in-depth kernel stuff, I'm sure the kernel people will be happy for more of themselves. (: Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OT: silence as an answer? (was: how to test out cron.c changes?)
On Tue 2001-01-02 (12:52), Gerhard Sittig wrote: > On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: > > Gerhard Sittig wrote: > > > > > > [ ... reminder after two weeks of silence ... ] > > > > Two weeks of silence is generally enough to let you know that > > no one is interested in this modification. If someone was, > > they'd generally have said something by now. > > Well, I don't come to the same conclusion here as you do and I'm > not so sure about it as you are. :) Silence as I see it is just > a sign for "nobody answered", without a reason to see why. It > could be work load or being offline or getting side tracked or > whatever as well as being not interested or disagreeing. And > finally I want to take the lack of disagreement (or the absence > of its statement) as a sign for "it's not completely wrong what I > want to do here". I tend to agree here - silence could mean many things. In this case, I can't see why people wouldn't want this - it's something that gets brought up time and again. > The experience will make me think twice next time if I'm in the > mood of spending my resources in the will to help and contribute > just to find myself sitting there ignored. Would I really feel > like having this kind of conversation, I could as well open my > fridge and talk to it ... :-| I think we can put this current silence down to holidays and getting sidetracked while trying to think of a reply - the question isn't particularly easy to answer, and people don't generally answer "I don't know". (: I remember reading this, and thinking "gee, what _is_ a good way to test DST changes?", and then promptly forgetting about it, because I never really deal with DST changes. I think the only way is the hard way - changing the date in increments and testing whether extra or no jobs are run. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux, Solaris, and NT
[ -hackers -> -chat ] On Tue 2000-12-26 (12:44), Marco van de Voort wrote: > > I ran into people at NASA who use Python because (beside being a good > > language) it isn't GPL. > > Pure paranoia. You don't have to share the code that is written IN > Python. Only modifications TO python (if it were GPL) > > > For legal and security reason they cannot > > share changes to code they make, so anything GPL is unusable. > > > So are programs that run on Linux required to be open source? I need > > to know. > > You may only shared link to GPL'ed packages, and the rest is up to > you. There is plenty of rhetoric on this, but the general view is that system libraries that provide functionality that is available in other non-GPL libraries (that is, libc, and friends) may be linked with, even if the specific library someone links it to is GPL (GNU libc is LGPL anyway, unless that's changed recently, but this theory allows proprietary programs to support free software systems where the libc is GPL [1]. However, deciding to link to other GPL libraries whose interfaces are specific to that library, and for which there are no competing non-GPL libraries (readline, for example), would mean having to make your code GPL. (This is perhaps why "shared linking" is deemed to be allowed by some. However, if this were so, I could take any arbitrary GPL program, wrap most of it up in a library, and shared link to it for most of the work, add some calls into it in my program, to create my own derived program which need not be GPL'd.) The Library General Public License used to be the more tolerant library license, but its use is now slightly discouraged, and it has been renamed the "Lesser" General Public License. The "Why Not LGPL" page suggests to LGPL only libraries that have equivalents in the non-GPL world, as making them GPL doesn't "give free software (sic) any advantage", and to GPL libraries that have no equivalents (giving readline as an example) to make sure proprietary developers cannot use it, unless they decide to use the GPL, or decide to simply write their own version and create the wheel over and over. This is what I perceive to be the general view, and should not be considered legal counsel. ;) 1: I wonder about just providing an object archive to the langauge and make the users link against their GPL libc if I was worried about license problems on a "free software only" system. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/pciconf vendors.h pciconf.8 pciconf.c
On Mon 2000-11-13 (12:24), Roger Hardiman wrote: > Mike Smith wrote: > > > > The downside of this is that it bloats pciconf from about 5k to about > > 130k. If someone feels passionately about this, they're welcome to add a > > compile-time option to leave the strings out. > > We will have to add this for PicoBSD where we want the kernel nice and > small. > > > Joe - you listening? pciconf isn't on any picobsd images I've seem. However, we can save a lot of space by reorganizing pci/pcisupport.c in such a way to make it easy to drop text identifiers for the pci devices. I seem to remember posting one way to do it to -arch a while back. It was a sizable win on the images I was playing with. Anyone interested can look at the (now heavily outdated) patch and recreate it. phk suggested there be one massive table, but I used a table per device type. I'm uncertain as to what others think on that. Cheers, Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Starting to code
[ -hackers => -chat ] On Wed 2000-10-18 (12:23), Wes Peters wrote: > Laurence Berland wrote: > > > > Wes Peters wrote: > > > > > > Laurence Berland wrote: > > > > > > > > What's a good place to start if you're a university student with limited > > > > hardware who wants to jump in and get going with the FreeBSD code. > > > > Right now I've got a PPro 200 with 32 MB of ram and lots of disk space > > > > (~50 gigs). 10 gigs or so is used by FreeBSD-Stable. I'm thinking of > > > > tossing Current on also, and maybe making the cvs repo a separate > > > > partition so I can share it between current and stable. > > > > > > I love it when people call a PPro 200 with 32 MB "limited hardware". My > > > first Free/NetBSD machine was a 386/40 with 8MB RAM and a 340 MB disk, and > > > it was state of the art except for lack of a CD-ROM drive. > > > > > I thought it was more than fast enough, and for most things it is, but > > KDE manages to crawl nonetheless... > > WindowMaker. ;^) I've recently discovered pwm, and I must say I can't imagine going back to anything else. The key feature is windows that share a common frame. I have three Eterms connected to the same frame with tabs at the top of the frame to choose the Eterm I want to see. This works even better for Netscape - I have about 12 or so Netscapes connected in one frame, and I just use meta-W to close ones I'm finished with and meta-N to add a new Netscape to the frame. No new windows rushing to the top in some weird place - all Netscape windows share the same mostly-maximised frame. I can shortcut with ctrl-shift-x where x is a single numeral to the number of the tab, or use ctrl-shift-N and ctrl-shift-P to move to the next and previous tabs respectively. Netscape even seems to crash less, but that's probably just wishful thinking. It _is_ chewing a whole 1.7 megs SIZE and 1.3 RES, though. Bad bad pwm, with quite a few frames and a number of tabs in each, all over about 6 workspaces. And I haven't manage to crash it yet, so I'm quite happy. Check out ports/x11-wm/pwm sometime. See the home page http://www.students.tut.fi/~tuomov/pwm/ for what passes for "themes". (: End of advertisement. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making /etc/defaults/rc.conf a configuration file.
On Wed 2000-10-04 (21:13), Doug Barton wrote: > Can you give more details about this process? I'm not sure how it would > work to change the list of conf files other than in the default location > if you're going to source the defaults anyway. defaults/rc.conf has ``rc_conf_files=/etc/rc.conf /etc/rc.conf.local'' rc.conf doesn't change rc_conf_files rc.conf.local sets rc_conf_files=/etc/rc.conf.script-generated rc.conf.script-generated doesn't change rc_conf_files So, we start with defaults/rc.conf, and read that in, and see listvar (rc_conf_files) says to look in rc.conf, so we read that in, and it doesn't set rc_conf_files, so we go to rc.conf.local, and read that in. It sets rc_conf_files to a file we haven't seen before, so we read it in. This may not be obvious, but it'll be obvious once it's documented. > > This only shows how to replace things using rc.conf - changing scripts > > to use periodic.conf is as simple as replacing > > > > if [ -r /etc/defaults/periodic.conf ] > > then > > . /etc/defaults/periodic.conf > > source_periodic_confs > > fi > > > > with > > > > rcfile=/etc/defaults/periodic.conf listvar=periodic_conf_files . /etc/sourceconf > > But you're basically doing exactly the same thing(s), just in a > different order. With all due respect to Neil, I stated previously that > I feel like this is a solution in search of a problem. I'm not arguing > for the status quo necessarily, I'm just concerned that when something > comes along down the road that *does* need to do something differently, > we will end up redoing all of this stuff again. I can't see how anything _can_ come down the road. It's an interface. If we want to read in configuration variables, we run the command. We don't care _how_ it does it, just that it does. If we need to change something, it'll be within that /etc/sourceconf file. > For what it's worth, I do not oppose the change, however I would like > to see some comments in the sourceconf file as to what is going on where > and why. I can't help feeling that sourceconf_start and sourceconf_dosrc > could just as easily be in the same function, but in my current state > I'm probably missing something. Also, in the sc.patch the entry for > /etc/rc has ". /etc/sourceconfs" instead of ". /etc/sourceconf". Oops, you're write, the patch won't work. That's what I get for generating the patch on another machine by hand, I suppose. The patch I've generated now (with just the one change) is the one I've actually been using to boot for the past few days. I don't mind adding mini-documentation to the scripts, I suppose, if that's required. > In any case, if the patch has been thoroughly tested under a variety of > different configurations, it's probably worth putting in -current. It > would probably be worth comparing what you're doing here to the work > that's happening on the rc files in netbsd that some here have discussed > bringing over, in whole or in part. We're not conflicting with anything that's happened in NetBSD. NetBSD's stuff is quite reasonable, but Daniel Sobral has pointed me at some things that he feels are missing, and I tend to agree after discussion with him. It is my plan (you probably heard me mentioning it) to investigate the NetBSD stuff properly, and compare it with slightly more featureful USM ( http://www.roguetrader.com/~brandon/sas/ ), which unfortunately may do too many things behind your back than what we're used to. However, I have a few things before that in my queue, and one of them is making it possible to develop a simple C API for reading our sh-style configuration, which somewhat requires that non-configuration code to disappear. (I should've continued when my suggestion was totally rebuffed last time, but I didn't have the time) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Making /etc/defaults/rc.conf a configuration file.
Hi,
With these patches, and the new tiny util 'sourceconf', we can make
/etc/defaults/rc.conf and /etc/defaults/periodic.conf configuration
files again, such that they can be parsed by things other than 'sh'.
It also allows you to set 'rc_conf_files' (or, actually, whatever you
set filevar to) in lower places than the default file, so that you don't
change the default file.
This only shows how to replace things using rc.conf - changing scripts
to use periodic.conf is as simple as replacing
if [ -r /etc/defaults/periodic.conf ]
then
. /etc/defaults/periodic.conf
source_periodic_confs
fi
with
rcfile=/etc/defaults/periodic.conf listvar=periodic_conf_files . /etc/sourceconf
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
Index: etc/netstart
===
RCS file: /home/ncvs/src/etc/netstart,v
retrieving revision 1.55
diff -u -r1.55 netstart
--- etc/netstart2000/04/27 08:43:47 1.55
+++ etc/netstart2000/10/03 01:14:04
@@ -9,13 +9,9 @@
# the network by hand, this script will do it for you).
#
-# If there is a global system configuration file, suck it in.
-if [ -f /etc/defaults/rc.conf ]; then
- . /etc/defaults/rc.conf
- source_rc_confs
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
-fi
+# Suck in the configuration variables
+#
+. /etc/sourceconf
if [ -f /etc/rc.network ]; then
. /etc/rc.network
Index: etc/pccard_ether
===
RCS file: /home/ncvs/src/etc/pccard_ether,v
retrieving revision 1.18
diff -u -r1.18 pccard_ether
--- etc/pccard_ether2000/09/07 03:06:06 1.18
+++ etc/pccard_ether2000/10/03 01:02:26
@@ -9,12 +9,7 @@
# Suck in the configuration variables
#
-if [ -r /etc/defaults/rc.conf ]; then
- . /etc/defaults/rc.conf
- source_rc_confs
-elif [ -r /etc/rc.conf ]; then
- . /etc/rc.conf
-fi
+. /etc/sourceconf
interface=$1
shift
Index: etc/rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.230
diff -u -r1.230 rc
--- etc/rc 2000/08/21 14:37:52 1.230
+++ etc/rc 2000/10/03 01:13:43
@@ -34,14 +34,9 @@
fi
fi
-# If there is a global system configuration file, suck it in.
+# Suck in the configuration variables
#
-if [ -r /etc/defaults/rc.conf ]; then
- . /etc/defaults/rc.conf
- source_rc_confs
-elif [ -r /etc/rc.conf ]; then
- . /etc/rc.conf
-fi
+. /etc/sourceconfs
# Configure ccd devices.
#
@@ -564,18 +559,13 @@
echo .
# Do traditional (but rather obsolete) rc.local file if it exists. If you
-# use this file and want to make it programmatic, source /etc/defaults/rc.conf
+# use this file and want to make it programmatic, source /etc/sourceconf
# in /etc/rc.local and add your custom variables to /etc/rc.conf, as
# shown below. Please do not put local extensions into /etc/rc itself.
# Use /etc/rc.local
#
# rc.local
-# if [ -r /etc/defaults/rc.conf ]; then
-# . /etc/defaults/rc.conf
-# source_rc_confs
-# elif [ -r /etc/rc.conf ]; then
-# . /etc/rc.conf
-# fi
+# . /etc/sourceconf
#
# ... additional startup conditionals ...
# rc.local
Index: etc/rc.devfs
===
RCS file: /home/ncvs/src/etc/rc.devfs,v
retrieving revision 1.8
diff -u -r1.8 rc.devfs
--- etc/rc.devfs2000/04/27 08:43:48 1.8
+++ etc/rc.devfs2000/10/03 01:14:34
@@ -1,14 +1,9 @@
#
# $FreeBSD: src/etc/rc.devfs,v 1.8 2000/04/27 08:43:48 sheldonh Exp $
#
-# If there is a global system configuration file, suck it in.
+# Suck in the configuration variables
#
-if [ -r /etc/defaults/rc.conf ]; then
- . /etc/defaults/rc.conf
- source_rc_confs
-elif [ -r /etc/rc.conf ]; then
- . /etc/rc.conf
-fi
+. /etc/sourceconf
# Setup DEVFS, ie permissions, links etc.
#
Index: etc/rc.diskless2
===
RCS file: /home/ncvs/src/etc/rc.diskless2,v
retrieving revision 1.6
diff -u -r1.6 rc.diskless2
--- etc/rc.diskless22000/04/27 08:43:48 1.6
+++ etc/rc.diskless22000/10/03 01:04:43
@@ -5,12 +5,7 @@
# If there is a global system configuration file, suck it in.
#
-if [ -r /etc/defaults/rc.conf ]; then
- . /etc/defaults/rc.conf
- source_rc_confs
-elif [ -r /etc/rc.conf ]; then
- . /etc/rc.conf
-fi
+. /etc/sourceconf
mount_mfs -s ${varsize:=65536} -T qp120at dummy /var
var_dirs="run dev db msgs tmp spool spool/mqueue spool/lpd spool/output \
Index: etc/rc.firewall
===
RCS file: /home/ncvs/src/etc/rc.firewall,v
retrieving revision 1.37
diff -u -r1.37 rc.firewall
--- etc/rc.firewall 2000/08/30 13:14:32 1.37
+++ etc/rc.f
Re: device naming convention
On Mon 2000-09-18 (14:42), Marc Tardif wrote: > > > 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a > > > for reading and writing (of course, this is assuming > > > block i/o of multiples of 512 bytes)? > > > > Nope, using raw devices is almost always wrong, and we even got rid of > > raw device in latter versions of FreeBSD. A "raw" device is an > > _unbuffered_ device. It has nothing to do with formats or types. > > > Got rid of raw devices in later versions of FreeBSD? What if I purposely > want unbuffered io? There are instances, such as with databases, where the > buffer cache is useless. > > I understand that in many cases, databases using the raw device > practically reinvent the wheel by programming what is effectively another > filesystem (which, by the way, is most likely slower than bsd's ffs). Even > Oracle, which used to be one of the "you gotta use a raw partition if you > want any speed at all" type, has moved into the "use a normal partitoin or > regular file unless you do things like sharing a RAID between two hosts" > camp. > > Yet, there are still isolated cases where raw io can be beneficial. What > should I do for raw io in later versions of FreeBSD? We didn't get rid of raw devices. We got rid of block devices, and kept character devices. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
On Tue 2000-09-19 (00:54), Daniel C. Sobral wrote: > > Lastly, where else could I have found this information other > > than asking on the FreeBSD mailing list? > > Beats me, but it _should_ be in the handbook. A basic device naming overview, as well as some simple disk layout information, is available in http://www.FreeBSD.org/handbook/disks.html Of course, noone reads documentation, so I don't know why I bother. (: Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_ifattach() issue
On Sun 2000-08-06 (13:28), Archie Cobbs wrote: > > > No interface should be attached twice, Ethernet or other, right? > > > So try this patch and find out which driver is broken. > > > > I think the concern was because the semantics to attach devices changed, > > meaning that drivers from before no longer work. > > Hmm.. my understanding was that it was never OK to attach the > same interface twice (without detaching in between). So if this > behavior worked before then it was just "luck". > > In any case, IMHO in the future it doesn't make sense to allow > an interface to attach twice... what would that mean anyway? > > Admittedly there may be a backward compatibility problem, but > it seems like the origin of the problem is in the driver, not > the ether_attach() routine. Using dev/awi/awi.c as an example: sc->sc_dev.dv_xname, sc->sc_mib_phy.IEEE_PHY_Type == AWI_PHY_TYPE_FH ? "FH" : "DS", sc->sc_tx_rate / 10, ether_sprintf(sc->sc_mib_addr.aMAC_Address)); - if_attach(ifp); #ifdef __FreeBSD__ - ether_ifattach(ifp); -#if NBPFILTER > 0 - bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); -#endif + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); #else + if_attach(ifp); ether_ifattach(ifp, sc->sc_mib_addr.aMAC_Address); #if NBPFILTER > 0 bpfattach(&ifp->if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); In other words - if_attach is no more. But, older drivers still use if_attach, and thus when ether_ifattach occurs, that's the second time that happens. Of course, I have no idea how the ether_ifattach argument change affects things - I'm just guessing as to why Dennis may be asking. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_ifattach() issue
On Sun 2000-08-06 (12:44), Archie Cobbs wrote: > No interface should be attached twice, Ethernet or other, right? > So try this patch and find out which driver is broken. I think the concern was because the semantics to attach devices changed, meaning that drivers from before no longer work. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Berkeley make: evaluations inside for loops
On Thu 2000-08-03 (13:31), Sheldon Hearn wrote:
> Can anyone explain to me why the first Makefile works and yet the second
> Makefile doesn't? The second Makefile produces the following error
> messages on ``make test''
>
> | "Makefile", line 1: Malformed conditional (widget == ${BAZ})
> | "Makefile", line 1: Need an operator
> | "Makefile", line 3: if-less endif
> | "Makefile", line 3: Need an operator
> | "Makefile", line 9: Need an operator
> | make: fatal errors encountered -- cannot continue
>
> #Makefile1:
> FOO= widget
> BAZ= widget
> BAR=
> .if ${FOO} == ${BAZ}
> BAR= equal
> .endif
>
> test:
> echo BAR=${BAR}
>
> #Makefile2:
> BAZ= widget
> .for FOO in ${BAZ}
> .if ${FOO} == ${BAZ}
> BAR= equal
> .endif
> .endfor
>
> test:
> echo BAR=${BAR}
Makefile2 expands to:
BAZ= widget
.if widget == ${BAZ}
BAR= equal
.endif
And '.if' only takes "expressions", which can be comparisons (ie, "!=",
"=="), which in turn must have a variable on the left hand side. (don't
ask me why)
Therefore, you should use:
.if ${BAZ} == ${FOO}
instead.
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: /tmp on a ramdisk?
On Fri 2000-07-28 (17:23), Doug Barton wrote: > Ted Sikora wrote: > > > > A while ago several people suggested using /tmp on a ramdisk along with > > softupdates. Right now I am running several production servers with > > 4.1-STABLE with softupdates. I'm really happy with the performance. What > > benefits would I realize using /tmp on a ramdisk? > > CW on this is varied, but the current trend is that /tmp on a md is just a > waste of ram, since (basically) everything in /tmp is in ram twice. I think that's MFS, not MD. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PR 10548: more userful ifconfig behaviour without args
Hi, There are plenty of PRs languishing without comment in the PR database, and this is one that requires a "implement and close it" or "here's a good reason not to do this, and close it" response. Any takers? Reply-To set to myself. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PATCH src/etc/root : more->less
On Tue 2000-07-11 (14:50), Michel Oosterhof wrote: > [snip] > > > > setenv EDITOR vi > >-setenv PAGER more > >+setenv PAGER less > > setenv BLOCKSIZE K > > > > I thought 'less' was in a port? Do you want to refer to programs that > need to be installed from a port first? 'less' will be in 4.1 and beyond. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: style(9)
On Fri 2000-06-30 (11:38), Martin Horcicka wrote: > 2. Citation: > > Indentation is an 8 character tab. Second level indents are four spaces. > > while (cnt < 20) > z = a + really + long + statement + that + needs + > two lines + gets + indented + four + spaces + > on + the + second + and + subsequent + lines. > a. What does it mean `second level indents'? Is it the indentation of >expressions that cannot fit to one line (as in the example above) or >is it any indentation except of the first tab? It's continuation lines, as the example states. All new statements occur on tab boundaries, whereas continuation lines are tabs to the previous tab boundary, plus 4 spaces. while (cnt < 20) if (foo == bar) baz(); > b. Aren't 8 characters too many? No. Anyway, you can set your tab size to whatever you want. So long as it is a _tab_, and not 2 or 4 or 8 spaces. If you're heading into the margin constantly, you should simplify your code, or break it up into (preferably reusable) functions that perform one task. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Mon 2000-06-19 (11:45), Neil Blakey-Milner wrote: > 'linuxbios' will only support booting off Linux partitions? > > I doubt they're replacing a multi-purpose, occasionally > not-all-that-clever thing, with a single-purpose very-often > not-all-that-clever thing? Ah wait, having read a bit more, they are. Good luck to them. I would have thought that redo-ing the entire BIOS would be a bit extreme. A 'simpler' serial console video/keyboard interaction firmware chip would have been nice. If you really want to be funky, add in network support for TCP/IP-based BIOS interaction. Otherwise, for the five-nines, replacing the whole BIOS is extreme. (says he, wondering why malfunctioning hardware tends to make his brain malfunction) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu 2000-06-15 (15:25), Ronald G Minnich wrote: > well linuxbios is what I started here, and I pinged some folks on this > list about supporting freebsd as well as linux, and got a 'no interest' > back from some folks. > > I'm still up for it. I think it's easy. 'linuxbios' will only support booting off Linux partitions? I doubt they're replacing a multi-purpose, occasionally not-all-that-clever thing, with a single-purpose very-often not-all-that-clever thing? What 'support' will FreeBSD require in 'linuxbios'? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu 2000-06-15 (14:03), Marinos J . Yannikos wrote: > On Thu, Jun 15, 2000 at 01:47:17PM +0200, Neil Blakey-Milner wrote: > > The PR number might be useful, if you have it. If it's not in the PR > > database, then you should submit it. That way we get to lay blame > > *grin*. > > Sorry... It was in the subject: PR 16318. I must add that I'm not > altogether certain that there isn't a way to circumvent the problem > by initialising the network differently, but I tried ... erk, my apologies. My mind tends to forget the subject line by the time the body appears. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu 2000-06-15 (13:50), Marinos J . Yannikos wrote: > I have been using William Carrel's bugfix for several months without > problems, but for some reason it isn't in the main source tree yet, so > cvsup overwrites the patched net/route.c sometimes. > > Does the bugfix break something? If not, why isn't it in 3.4-STABLE yet? > It is necessary for the above configuration (or isn't it? I couldn't find The PR number might be useful, if you have it. If it's not in the PR database, then you should submit it. That way we get to lay blame *grin*. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Remote syslog with a tag ?
On Tue 2000-06-13 (22:40), Bernd Walter wrote: > > I've often thought it would be nice to be able to get syslogd to > > make choices based on hostname. I'm sure a patch would be easy > > enough to produce, but the trick would be to produce a good syntax > > fox syslog.conf. Are there any syslogds that can do this? What > > syntax do they use? > > I have a patched version to do this. > If anyone is interessted I'm producing diffs. I'm sure many people are interested. Send a PR, or patches to [EMAIL PROTECTED] Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
On Thu 2000-06-08 (11:43), Luigi Rizzo wrote: > sorry if i lost part of the discussion, but why dont you > just associate a quota with a rule and specify one of the > two possible results when exceeding quota: > >ipfw match-upto 20MB >ipfw deny-above 20MB > > where the first syntax does not match when the rule's counters > are above the quota, the second one denies the pkt when above quota. > > It looks of trivial implementation and rather easy to understand. > You'd just need a new ipfw command to increase/decrease/set counters to > a specific value rather than just zero them. Well, it may or may not be able to cover a situation I'm thinking about now: You have a server farm, or just a single machine with multiple IP addresses assigned to various jails, and you'd like them to be able to be able to be able to get anywhere. But, always allow traffic to and from a specific set of controlling machines, and also their owner company, and maybe a specified port for some form of VPN. If they exceed a first level of traffic, a dummynet rule kicks in slowing them down (alternate queueing system quite possibly too) just a bit, and as they break certain levels, slow them down more and more to non-specific sites. The specific sites may or may not contribute to the quota, but must remain available. Also, there may be a user account on the multi-user machine doing these rules who can log in to the base system to do certain forms of maintenance not easily available in the jail. Traffic caused by this person should also fall within the same quota. Further, a company may have two IP-based virtual hosts, or two or more servers in the server farm for some reason, sharing the same quota, and so forth. I just thought that: ipfw quota 1 config quota 20MB ipfw add quota 1 ipfw add quota 1 ipfw add quota 1 ipfw add allow ip from any to any uquota 1 ipfw add pipe 1 ip from any to any oquota 1 ... would be the extensible and more useful way of doing this, and most other IP-based quota systems. It also means you can set up your quotas, change the traffic numbers, change the match sets, all without changing your basic firewall rules. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
On Wed 2000-06-07 (19:18), Poul-Henning Kamp wrote: > It should be possible to say say > >ipfw deny all ip from any to any exquota any > > as well as: > >ipfw deny all ip from any to any exquota guest How about: ipfw quota 1 config quota 10MB (and similar conversions as pipe for MB, Mb, kB, kb, &c.) ipfw quota 2 config quota 20MB (and similar conversions as pipe for MB, Mb, kB, kb, &c.) ipfw add quota 1 ip from any to any (add to quota 1's count) ipfw add quota 2 ip from any to any (add to quota 2's count) ipfw add allow ip from any to any uquota 1 (allow unhindered ip when under quota) ipfw add deny ip from any to any oquota 2 (deny ip when over high quota) ipfw add pipe 1 ip from any to any oquota 1 (dummynet ip when over low quota) Possibly also rules like: ipfw add pipe 1 ip from any to any oquota 1 uquota 2 (dummynet middle quota) ipfw add pipe 2 ip from any to any oquota 2 uquota 3 (get even slower) ipfw add deny ip from any to any oquota 3 (total stop) (allowing for slower and slower service instead of just two levels) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
On Wed 2000-06-07 (08:48), Coleman Kane wrote: > Well, a lot of drivers aren't modules yet. It was basically an idea to > move the kernel more towards a modular implementation. There will be a > large number of modules if all the drivers were to become modules. It > may not be, say, to everyone's liking to manually load a good deal of > those. Plus, there are many people who use FreeBSD for desktop or home > situations and even those who don't know a extremely large amount > about computer hardware and all. This would be a nice "option" to have > for some. If you're suggesting more modularity, that's great. You just confused me by mentioning "kerneld". I'm all for more modules. I still had problems with why you wanted a 'kerneld', but rwatson's suggestions about security, pccardd, usbd, do make sense. I do like the way the auto-ifconfig and auto-mount stuff works, though. At the very least, I'd like a probe-only way to find out what devices are available, given a bunch of device driver modules. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
On Wed 2000-06-07 (01:43), Coleman Kane wrote: > I really don't think that stupidity is the issue, there are plenty of > devices which you use very discretely which may only need support > every once in awhile. Once again, I don't think you're giving me enough clues as to what you're aiming at. While I believe it's the sysadmin's choice whether to unload modules, it's also hir choice as to whether to run a daemon that'll auto-unload unused modules. That part of your idea I can understand. I'd imagine it'd work great as a port. > It might be nice to start running on modules regularly. It would also > be useful to be able to update your device driver while running > freebsd, without needing to reboot. You can already do this. kldunload the old module, and kldload the new module. Or am I missing something again? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Write-protected floppy crash
On Tue 2000-06-06 (19:13), Oleg Derevenetz wrote: > When write-protected floppy mounted in R/W mode, write attempt to this > floppy follows kernel panic (dirty buffers) and reboot. Is this correct ? > The best way IMO is to always mount write-protected floppies in R/O mode. It's not 'correct', but it does happen, and is copiously documented and mentioned on various mailing lists. It would be nice if you could fix it *grin*. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
On Sun 2000-06-04 (23:06), Coleman Kane wrote: > Look through /modules... I'm still having problems working out what this will do. Can you explain the differences between the current way of doing things, and what your stuff will conceptually do? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Safe sourcing of rc files
On Wed 2000-04-19 (16:51), Neil Blakey-Milner wrote:
> I have another idea: We make a sh script named "rcsource" or whatever,
> which we source when we want to have the rc environment, stealing your
> code maliciously:
>
> /--
> sourcercs_sourced_files=
> sourcercs ( ) {
> local rc_conf_files
> for i in $*; do
> case "${sourcercs_sourced_files}" in
> *:$i:*)
> ;;
> *)
> sourcercs_sourced_files="${sourcercs_sourced_files}:$i:"
> echo $i
> if [ -r $i ]; then
> . $i
> sourcercs ${rc_conf_files}
> fi
> ;;
> esac
> done
> }
> sourcercs /etc/defaults/rc.conf
> \--
Unless someone comes back with negative feedback, I'll be pushing for a
commit for this (and all that depend on this change) on the weekend.
Consider this a request for review and comment.
Neil
--
Neil Blakey-Milner
Hacker In Chief, Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Safe sourcing of rc files
On Mon 2000-04-10 (00:10), Doug Barton wrote:
> +if [ -z "${sourcercs_defined}" ]; then
> +sourcercs_defined=yes
> +sourcercs ( ) {
> +local sourced_files
> +for i in ${rc_conf_files}; do
> +case "${sourced_files}" in
> +*:$i:*)
> +;;
> +*)
> +sourced_files="${sourced_files}:$i:"
> +if [ -r $i ]; then
> +. $i
> +fi
> +;;
> +esac
> +done
> +}
> +fi
I have another idea: We make a sh script named "rcsource" or whatever,
which we source when we want to have the rc environment, stealing your
code maliciously:
/--
sourcercs_sourced_files=
sourcercs ( ) {
local rc_conf_files
for i in $*; do
case "${sourcercs_sourced_files}" in
*:$i:*)
;;
*)
sourcercs_sourced_files="${sourcercs_sourced_files}:$i:"
echo $i
if [ -r $i ]; then
. $i
sourcercs ${rc_conf_files}
fi
;;
esac
done
}
sourcercs /etc/defaults/rc.conf
\--
Anyway, this'll do something I've been considering missing - the ability
to set more rc_conf_files in /etc/rc.conf and friends. It also means a
total lack of sh-script in /etc/defaults/rc.conf and /etc/rc.conf, which
means that we can start developing something in C that can read those
files (libconf, Daniel?).
Basically, it localizes rc_conf_files so that you don't lose any you've
specified before. So, in /etc/defaults/rc.conf, it sets rc_conf_files
to "/etc/rc.conf /etc/rc.conf.local", and when it runs /etc/rc.conf,
rc_conf_files changes to "/etc/foo.conf", and that'll be read. After
it's finished, it pops up two spaces, and goes on to /etc/rc.conf.local.
A file will only ever be sourced once.
One possible extension may be a specifier of a preprocessor for a file:
preprocessor__etc_defaults_rc.conf='cpp' will be checked if sourcercs is
run on /etc/defaults/rc.conf, and it will be passed through cpp before
trying to understand it. This should be extensible enough to avoid the
need of sh-script to get a value for a variable.
Any more ideas?
Neil
--
Neil Blakey-Milner
Hacker In Chief, Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: zsh compdef collection for FreeBSD
On Fri 2000-03-24 (16:52), Doug Barton wrote:
> I use the following in my .bashrc. I'm operating on the assumption
> that zsh has aliases of some sort, otherwise feel free to ignore this
> entire post. :)
My ~/.tcsh/os-FreeBSD (which get auto-called by my .tcshrc) has:
/
setenv PR_FORM ~/.send-pr
# bsd make allows knowing the targets like so:
uncomplete make
complete make 'p@*@`if -e Makefile make -dg1 -q | grep "^[^.#][-_a-z. \t]*:" | awk
'"'"'{print $1}'"'"'`@'
# if I have a local copy of the cvs tree, add aliases to easy moving
# into it
alias ncvs 'if ( "\!*" == "" ) then \
pushd $NCVS/`pwd | cut -f 3- -d/`; \
else \
pushd $NCVS/\!*; \
endif'
complete ncvs "p%*%D:$NCVS/%"
alias uncvs 'popd'
complete pkg_delete 'p%*%D:/var/db/pkg/% %'
complete pkg_info 'p%*%D:/var/db/pkg/% %'
# indt alias compares given code to code given by indent(1)
alias indt 'cat \!\!:1 | indent -st | diff \!\!:1 - | $PAGER'
# show the rlog of a file through favourite pager
alias rl 'rlog \!:1 | $PAGER'
/---
That basically sets up 'make' completion:
(nbm@mithrandr) /usr/src> make
afterdistribute everything move-aout-libs
all hierarchyobj
aout-to-elf includes objlink
aout-to-elf-buildinstall regress
aout-to-elf-install installkernelrerelease
...
It also completes pkg_delete and pkg_info:
(nbm@mithrandr) /usr/home/nbm> pkg_delete c
cdd-1.0/checkpassword-0.81/ cvsup-mirror-1.0/
cdrecord-1.8a33/cvsup-bin-16.1/ cvsupd-bin-16.1/
ncvs pops me into the cvs tree of the directory I'm in:
(nbm@mithrandr) /usr/src/contrib/cvs> ncvs
(nbm@mithrandr) /home/ncvs/src/contrib/cvs>
uncvs pushes me back. ncvs could be made much more intelligent, of
course.
Anyway, enough of that. Time for me to finally learn zsh.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
3.x -> 4.x kernel config converter
Hi, I wrote a quick hackish perl script to hopefully automatically convert 3.4 kernel configurations to 4.0 configurations. I can pipe RELENG_3 LINT through it and get a 4.0 config'able configuration, but I'm not sure if it's likely to produce booting kernels. Anyway, I thought some people might be interested in this - if it works well enough, it might even be useful to put in the tools directory, or integrate it into any 'update' target that may appear. It's at http://people.FreeBSD.org/~nbm/three-to-four-conf.pl Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
On Fri 2000-03-10 (11:02), Didier Derny wrote: > I've just read the announcement of the merge of BSDI and Walnut Creek > CDROM. (March 10 2000). > > I guess it's a sad day for FreeBSD. I can't imagine how a company selling > it's own BSD could at the same time let another BSD free. Let's hope your mailbox doesn't get filled with replies. Which announcement did you read? You really should read the daemonnews one, as it covers a lot of stuff that should reassure you. The slashdot interviews with Bob, Jordan, and Mike should also do so. In my discussions with the various stakeholders, I must say I'm confident of this move. > I think it is time to think to something else NetBSD ? OpenBSD ? Linux > (which one?) One of the things that I can assure you, is that if anything untoward occurs (which I'm sure will not) it's easy enough to just rename the project and carry on with the existing code. There's nothing that can be done to prevent it, and you'd basically have FreeBSD again. Walnut Creek doesn't own FreeBSD, so BSDI can't buy FreeBSD via Walnut Creek. So, no, FreeBSD certainly isn't dead. If anything, things will become even more lively! (: Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re/Fwd: freebsd specific search
On Wed 2000-02-02 (11:18), Michael Bacarella wrote: > > systems have the highest availability rate possible. Over the last few > > years, I have replaced almost all of our Linux-based servers with FreeBSD, > > due to the quality-control measures that the FreeBSD development team have > > implemented. > > Not to start a flame-fest or anything (but who doesn't love em?), I hear > the above quite a lot. (I don't like them.) > I certainly couldn't put up a reasonable arguement for either side in > Slackware Linux vs. FreeBSD. > > Could you? Nope. I can't say I know Slackware or its quality-control measures, so could you please answer some questions for me? What sort of quality-control measures does Slackware have? Where do I access their cvs tree? Where do I access their problem reports? Where do I subscribe to get every commit message? How long are their code freezes? How many committers do they have? What mechanism creates their releases? Where do I get release-candidates? (I apologize if that sounds argumentative, it really isn't. It just addresses some of the things that I do know about FreeBSD with regards to quality control, and what I don't know about Slackware in order to answer your question.) Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question about boot loaders
On Thu 1999-12-09 (02:46), Robert Watson wrote: > Once we get into boot2 land, I recognize the FreeBSD-specific loading > code, etc. What I don't know much about is those first three 512-byte > chunks of code. Boot0 appears to be booteasy, but given some ignorance > about the i386 boot process, I'm not sure whether it's loaded by mbr, or > by the bios, and where it lives partition-wise. Similarly, how boot1 fits > into it the whole scheme--I assume this is FreeBSD-specific as it knows > about boot2, but don't know where it lives, etc. Preferably, afterwards, > also drop the results into sys/boot/i386/README. :-) I wrote up some basic stuff, which doesn't seem quite to describe what you're after, but which may be of use, at http://rucus.ru.ac.za/~nbm/boot/ It's intended for the handbook, but I haven't had time since starting my new job to work on it much more. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Update the name of a filesystem (more details)
On Mon 1999-10-18 (15:46), Zhihui Zhang wrote: > I am trying to change the mount point of a mounted filesystem (from > /testme to /test) with the update option (-u): That's not how -u works. From the man page: -u The -u flag indicates that the status of an already mounted file system should be changed. Any of the options discussed above (the -o option) may be changed; also a file system can be changed from read-only to read-write or vice versa. > # mount /dev/wd0s2e /testme > # mount -u /dev/wd0s2e /test > mount: /dev/wd0s2e on /test: specified device does not match mounted > device This is because, as stated above, you can only change the options of the mounted filesystem, not its mountpoint. > Why it does not work (I know I can umount first without using the update > option)? Any help is appreciated. This (umount then mount) is the way to change mountpoint names. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: updating packages automatically, etc.pp.
On Wed 1999-09-29 (18:04), Conrad Sabatier wrote:
> It only tries to upgrade ports which have a single version installed,
> basically because I haven't gotten around yet to handling the parsing
> of pkg_version's output where more than one version of a port is
> installed. :-)
Patch at http://rucus.ru.ac.za/~nbm/pkg_version-patch
> The script checks to make sure that the new version builds
> successfully and is ready to be installed before deleting the old
> version (the reason for all those "&&" thingies).
There may be a problem if pkg_delete returns an error code if it is
missing files, or something.
You also lose if make install fails, which isn't very often,
admittedly.
One solution I've got working is running pkg_create using the
information in /var/db/pkg/foo-1.0/ much like the fake-pkg target
in ports. Then you can "make install clean || pkg_add foo-1.0" to
make sure you at least get a working copy in the end.
(This ties in with plans to make changing and upgrading ports
back-out-able, which was mentioned as something nice we should aim
for.)
> It should probably also check to see
> whether a port is interactive or not, but that's another thing I have
> yet to do. :-) Ignore the line wrap, by the way:
"make BATCH=1", instead of just "make".
> #!/bin/sh
>
> for old_pkg in `pkg_version -v | grep '<' | awk '{print $1}'`
> do
> new_pkg=`echo $old_pkg | sed 's/-[0-9].*$//'`
>
> echo Upgrading $old_pkg
>
> cd /usr/ports/*/${new_pkg} && make && pkg_delete -f $old_pkg
> && make install clean
> done
You also lose any "dependency" information, which isn't too great.
You can find the directory of alternate version ports in /usr/ports/INDEX
(much like pkg_version) - grep for the exact version specified in
the return from pkg_version, and you pick up the correct ports
directory as a bonus.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A new package fetching utility, pkg_get
On Mon 1999-09-27 (10:22), Andrew Reilly wrote: > I've longed for a mechanism to keep the ports that I use as > up-to-date as the rest of my FreeBSD system. Unfortunately, > some ports I don't use very often, and so forget that they're > there. > > Unfortunately (again), the port name-version_number identifier > isn't _quite_ unique enough to use as a key for tracking ports. > For example: ssh and docbook have multiple versions for the same > base name installed concurrently. > > What I'd like is a little weekly crontab script that runs after > my weekly ports cvsup, and tells me which of the ports that I > "subscribe to" has changed, so that I can think about rebuilding it. I have patches to pkg_version that teach it to handle multiple versions installed and in the ports INDEX, which works pretty well in my use, albeit a bit slower than pkg_version. They are at http://rucus.ru.ac.za/~nbm/pkg_version-patch I've got a local patch at home that can take a list of packages (like "pkg_version gtk docbook ssh") and checks only those packages for changes - it does break current command-line interpretation - usually pkg_version takes a path to the INDEX as its only argument, my patches use a -f location option. Plug in those patches Nik has, and you can have intelligent automatic updating (although sometimes you'll clobber your configuration files). Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
return j;
> }
Or, if you really want to, use your other return scheme.
In other words, initialize j, probably to 0.
Neil
--
Neil Blakey-Milner
n...@rucus.ru.ac.za
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
return j;
> }
Or, if you really want to, use your other return scheme.
In other words, initialize j, probably to 0.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Wed 1999-09-01 (16:40), Andrzej Bialecki wrote: > > :I vote for two spaces after the period before the start of a new sentence. > > :Even in the digital age, I've always found that the two spaces make > > > I guess they don't teach manual typewriting classes any more :-) > > It *had* to be two spaces or you got seriously marked down! > > Doesn't apply here in Europe. I vote against putting in too much > stars&stripes dependent stuff... ;-) I was about to mention something about Britain, but I suppose we can't go about calling them European. (: And (at least in my school, which tries its best to appear British and colonial, and more recently my university) here in .za the convention persists. Of course, we could, like me, just never use more than one sentence per paragraph (making sure we use the correct conjunctions), which has always caused havoc in my brief involvement in user education and documentation. I'd also like to advocate the return of the semi-colon; it is underused. (Follow-ups to -chat) Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Wed 1999-09-01 (16:40), Andrzej Bialecki wrote: > > :I vote for two spaces after the period before the start of a new sentence. > > :Even in the digital age, I've always found that the two spaces make > > > I guess they don't teach manual typewriting classes any more :-) > > It *had* to be two spaces or you got seriously marked down! > > Doesn't apply here in Europe. I vote against putting in too much > stars&stripes dependent stuff... ;-) I was about to mention something about Britain, but I suppose we can't go about calling them European. (: And (at least in my school, which tries its best to appear British and colonial, and more recently my university) here in .za the convention persists. Of course, we could, like me, just never use more than one sentence per paragraph (making sure we use the correct conjunctions), which has always caused havoc in my brief involvement in user education and documentation. I'd also like to advocate the return of the semi-colon; it is underused. (Follow-ups to -chat) Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: df and procfs
On Thu 1999-08-26 (12:33), Ben Rosengart wrote: > On Thu, 26 Aug 1999, Neil Blakey-Milner wrote: > > > On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > > > > > (The man page seems to be in error, though, when it says that "sysctl > > > vfs" tells what kinds of filesystems are available.) > > > > lsvfs should give a good indication. > > Should I submit a patch to the man page? You need to ask? (: I'll do it if you haven't. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: df and procfs
On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > df -t noprocfs > > > > and voila no procfs in the output ! > > Well that works. Thanks. > > (The man page seems to be in error, though, when it says that "sysctl > vfs" tells what kinds of filesystems are available.) lsvfs should give a good indication. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: df and procfs
On Thu 1999-08-26 (12:33), Ben Rosengart wrote: > On Thu, 26 Aug 1999, Neil Blakey-Milner wrote: > > > On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > > > > > (The man page seems to be in error, though, when it says that "sysctl > > > vfs" tells what kinds of filesystems are available.) > > > > lsvfs should give a good indication. > > Should I submit a patch to the man page? You need to ask? (: I'll do it if you haven't. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: df and procfs
On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > df -t noprocfs > > > > and voila no procfs in the output ! > > Well that works. Thanks. > > (The man page seems to be in error, though, when it says that "sysctl > vfs" tells what kinds of filesystems are available.) lsvfs should give a good indication. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon 1999-08-23 (09:59), Cillian Sharkey wrote: > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. > > Ideas / Comments / Suggestions ? I have changes to this effect active on a box not here, I'll see if it is up-to-date enough to generate patches, and send them on to help you, if necessary. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On Mon 1999-08-23 (09:59), Cillian Sharkey wrote: > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. > > Ideas / Comments / Suggestions ? I have changes to this effect active on a box not here, I'll see if it is up-to-date enough to generate patches, and send them on to help you, if necessary. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sun 1999-06-27 (22:26), John Baldwin wrote: > > if people have their undies in a wad over this, can't they compile > > inetd without LIBWRAP? > > Ahem.. > > Let's say I have two services, foo and bar, with food and > bard. I want to wrap food, but *NOT* bard and they are both in > /etc/inetd.conf. How do you propose to solve this with the internal > wrapping (which is a good idea, IMO as it eliminates an exec())? Run two copies of inetd? Seriously, if wrapping support can be tuned at runtime, and you can set up inetd to run with different configuration files (which you can), if those people who want to run both wrapped and non-wrapped services agree that this is an option, there needn't be a hack to do this sort of thing. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sun 1999-06-27 (22:26), John Baldwin wrote: > > if people have their undies in a wad over this, can't they compile > > inetd without LIBWRAP? > > Ahem.. > > Let's say I have two services, foo and bar, with food and > bard. I want to wrap food, but *NOT* bard and they are both in > /etc/inetd.conf. How do you propose to solve this with the internal > wrapping (which is a good idea, IMO as it eliminates an exec())? Run two copies of inetd? Seriously, if wrapping support can be tuned at runtime, and you can set up inetd to run with different configuration files (which you can), if those people who want to run both wrapped and non-wrapped services agree that this is an option, there needn't be a hack to do this sort of thing. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
