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: 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: 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: 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]-+ disclaimer 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 ;-) /disclaimer 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 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: 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: 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 (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 (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 (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)
elopment 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)
y'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: 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: 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
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: 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: 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: 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: 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 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: 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: 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: 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: 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 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: 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 action match pattern match-upto 20MB ipfw action match pattern 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 match-a ipfw add quota 1 match-b ipfw add quota 1 match-c 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: 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: 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: 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
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: 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
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: 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 starsstripes 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: 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 starsstripes 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: 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: 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 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 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 n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org 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
