Re: Crypto progress! (And a Biiiig TODO list)
> "Mark" == Mark Murray <[EMAIL PROTECTED]> writes: Mark> o A username may only be checked $number times per Mark> $timeperiod; after that, _all_ answers are silently Mark> converted to "no". Umm, massive DOS hole. Mark> o Daemon may only be invoked $number times per $timeperiod; Mark> refuses to fork after that. Another massive DOS hole. Mark> o Daemon will delay $timeperiod before returning answer. This is the correct way to deal with (perceived) attacks. Mark> ... etc. There are possibilities for DoS attacks, but the Mark> daemon talks only to a Unix Domain Socket, so finding the Mark> perp is easy. Not if the daemon has shut itself off due to load (#1 or #2 above) and you aren't currently logged in to the box. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes: Garrett> And what happens when the daemon is dead, has crashed, or Garrett> was never started? You incorporate my patches to inetd that teach it to listen on named sockets, and then run the daemon from there in wait mode. If inetd dies you're pretty much hosed, anyway. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes: >> You incorporate my patches to inetd that teach it to listen on >> named sockets, and then run the daemon from there in wait mode. >> If inetd dies you're pretty much hosed, anyway. Garrett> Think ``single-user mode''. In single user mode you're root by definition. If init wants roots password before going single user it can certainly go directly to the password file. (It's really no different than if you're serving up passwords via NIS.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
> "Christian" == Christian Weisgerber <[EMAIL PROTECTED]> writes: Christian> Commercial users need to get Christian> an explicit license from RSA Inc., which from what I Christian> hear you can't get in practice. Correct. The only option for commercial software (in the US) is to license the BSAFE libraries from RSA. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
status of 'device awe' ?
LINT has an entry for an 'awe' device, however there doesn't appear to be any corresponding source code in the tree. Is this device dead? If so, the entry should be removed from LINT, or an appropriate comment added. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Process cleanup (was Shared memory ...)
> "John" == John Polstra <[EMAIL PROTECTED]> writes: John> Applications need to clean up after themselves. The OS has John> no way of knowing whether an application wants its shared John> memory segments to survive after it terminates. Tricky when the program crashes. Remember that a bug-free application can still crash due to buggy shared-libraries. I'm too lazy to look right this second ;-) ... do atexit() functions get run when a process takes (say) a segmentation fault? --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMTP AUTH (was Re: On hub.freebsd.org ...)
> "Gary" == Gary Palmer <[EMAIL PROTECTED]> writes: Gary> There are two `standards' from SMTP Auth out there ... one Gary> by Netscape (which is that rfc), and one by M$. To date, Gary> only Netscape 4.5 and higher (I believe), and products from Gary> Software.com (i.e. InterMail) support the netscape version Gary> (although I haven't looked in a few months, so I could be Gary> wrong). There is one SMTP AUTH, and it's defined in RFC 2554. Products I'm aware of that support SMTP AUTH (or will shortly) as defined in the RFC: Servers: PMDF (Innosoft), MDstore (Messaging Direct), Sendmail 8.10, Netscape Clients: Execmail, Mulberry. I'm sure there are others. The major use for SMTP AUTH will be in SUBMIT servers. The combination of SUBMIT + SMTP AUTH will make it possible to disable relay on SMTP servers without restricting mobile mail clients. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ps -e
> "Matthew" == Matthew Dillon <[EMAIL PROTECTED]> writes: Matthew> Why don't we get rid of the 'e' option to ps while we Matthew> are at it considering how much of a security hole it is. I wouldn't nuke it completely. Make -e a noop unless the real uid ps is running with matches the effective uid of the process being reported. And if ps is invoked with a real uid of 0, -e works as it does now. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
> "David" == David Malone <[EMAIL PROTECTED]> writes: David> I guess it goes with the "stop ps showing the environment" David> changes. If you remove one it makes sense to remove the David> other. After you verify that this change isn't going to break things that assume they can see the *argv list via ps(1). I.e. lightning bolts that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant style, but sometimes is the only workable solution. Where this could be an issue is binaries with multiple names. E.g. if bar is a symlink to foo, and you execute bar, ps (old style) reports: 83158 p0 S 0:00.00 bar (foo) I *suspect* in the new scheme when running non-root, you don't see bar show up. If that's the case, we've broken working code. Now, if instead printing *argv[] follows the -e semantics I posted to the list a couple of days ago, all should be well. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
> "Dieter" == Dieter Rothacker <[EMAIL PROTECTED]> writes: Dieter> Why would you want to define "correct" numbering the Dieter> non-spread-out numbering? Or did I misunderstand you? I Dieter> have all my disks as master drives on the channels. Now, Dieter> when I hook up another disk for backup or maintenance Dieter> purposes, my numbering is messed up. Or worse, on a file server where you lose a low-numbered disk, not only does that one go away, but everything higher numbered loses as well. This "feature" does nothing other than introduce a gratuitous backwards-incompatibility. There is nothing wrong with the "old" scheme. I've loathed this behaviour since it was introduced into SCSI/CAM, and would rejoice at its removal. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
> "Adam" == Adam <[EMAIL PROTECTED]> writes: Adam> As I understand it, cam or pre-cam or wd or ata it is simply Adam> an issue of defaults. If you plan to use disks that die or Adam> become removed, simply read LINT on how to wire your disk Adam> id's. I understand. The point is: why? I had a perfectly good working system. Why should I have to make changes to support this new behaviour? What is the "benefit" of the new system? All I see is a make-work project for all my kernel configuration files. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
> "Mike" == Mike Smith <[EMAIL PROTECTED]> writes: Mike> The "right" solution is and has always been to name your Mike> disks and mount them by name. Once devfs is a reality, Mike> we'll be able to do just this. Until then, the problem's Mike> not really as bad as you make it out to be. I like the assigned-name solution. I still don't like dynamic disk names. It's not a show-stopper by any stretch, but if you move disks around, (not uncommon on development machines) it's a pain. And while you're correct about the boot/fsck issues, adding a renumbering in /etc/fstab to my restart sequence isn't doing anything to get the machine back up quickly (or reliably). Anyway, enough of this -- I have config files to go hardwire :-) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of moving files (Re: make world broken building fortunes )
> "BSDman" == BSDman <[EMAIL PROTECTED]> writes: BSDman> one idea about /usr is to allow the admin to mount it BSDman> read-only. I didn't tried it but this would give some BSDman> level of security against modifications of the files there BSDman> in. This is particulary useful in a lab environment where you have xx workstations with local root, var, and swap NFS mounting an RO /usr. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Init (was MAKEDEV et al)
> "Peter" == Peter Jeremy <[EMAIL PROTECTED]> writes: >> And then we could telinit -on sshd telinit -off sshd Peter> This looks nice. The major problem I see is coming up with Peter> a secure mechanism for passing the daemon name from telinit Peter> to init. Named sockets work well for this sort of control channel. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) patches to bypass quietness prescribed by @-prefixed commands in Makefiles
I like the idea, but the -l flag conflicts with a different usage for SVR4 derived makes (on at least AIX, Irix, and Solaris): -l load Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a floating-point number). With no argument, removes a previous load limit. Maybe this should instead be a -d sub-option? And I like the idea of adding the -l functionality described above. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Review and commit of bin/14911?
Could someone with commit privs please take a look at bin/14911? I'd really appreciate it if that could get committed, and MFC'd into RELENG_4. Also, bin/6997 has been aging away for quite some time as well. Thanks, --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Review and commit of bin/14911?
> "David" == David O'Brien <[EMAIL PROTECTED]> writes: David> You might get more interest if you mention what the PR David> fixes. It adds missing binary/manpage links from opiekey to otp-md4 and otp-md5. Some of our remote users run software that semi-automates OTP logins, and that software expects the otp-* commands to be on the remote system. The opiekey(1) manpage also mentions the otp-* commands by name. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) patches to bypass quietness prescribed by @-prefixed commands in Makefiles
Chuck> Compatibility with those other makes is pretty low to begin Chuck> with, but it doesn't hurt, I guess, to allow for this. -dl Chuck> is ok with me. I just wouldn't consider the compatibility Chuck> thing a real issue if it weren't this easy to satisfy. It's not a big deal for me. I just get annoyed at all the seemingly gratuitous incompatibilities between the different versions of something as fundamental as make. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> "Ruslan" == Ruslan Ermilov <[EMAIL PROTECTED]> writes: Ruslan> It doesn't really matter what the home directory is set to Ruslan> (IIRC), but the shell must be uucico(8). No, this is wrong on both counts. By convention, the home directory of the uucp login has corresponded to the UUCP PUBDIR. Traditionally this was /usr/spool/uucppublic, and maps to /var/spool/uucppublic these days. Thus, if I wanted to copy a file to the public file area on machine b I would incant uucp file b!~ and the uucico on the remote end would expand the '~' to /usr/spool/uucppublic. This usage predates (and probably inspired) the common behavior of current shells handling of '~' expansion. While no modern UUCP I'm aware of uses the value of pw->pw_dir to derive PUBDIR, POLA would imply that the interpretation of '~uucp' should be the same for both the uucp(1) command and for shells that do ~ expansion. Therefore I would recommend keeping the UUCP home directory as /var/spool/uucppublic. If you want to be paranoid you make this directory owned by root.wheel and mode 0555 without breaking anything. As for the `uucp' account's shell, this should be set to /sbin/nologin. The purpose of the uucp entry in /etc/passwd is to provide a unique runtime uid for the setuid UUCP components. Note that there are some periodic maintenance scripts that should be run if you actively use UUCP. These traditionally run under the `uucp' identity, so you need to make sure that they will continue to function with /sbin/nologin. (Which they should, otherwise they would have barfed with uucico as the shell.) The shell for the uucp account should most certainly NOT be uucico! And you should *never* allow remote site UUCP logins (those that run uucico) under the `uucp' login, for obvious security reasons. Instead, create seperate unique logins for each remote site, just as you would for each of your shell accounts, but set the login shell to uucico. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> "Garrett" == Garrett Wollman <[EMAIL PROTECTED]> writes: Garrett> I remember, back in the mists of ancient time, it was Garrett> common practice to provide ``anonymous UUCP'' service Garrett> along the lines of anonymous FTP in (what was at that Garrett> time) ARPANET. Yup, I used to run one of those (ncc). osu-cis was probably the grandaddy of the anonymous UUCP sites. The convention seemed to be to use the login 'nuucp' for anonymous passwordless access. (And I wouldn't call it common -- there were only a handful sites that provided this type of service.) Garrett> I find it hard to imagine anyone doing so Garrett> today, but OTOH I find it hard to imagine anyone using Garrett> UUCP at all today, so it is obviously my imagination Garrett> which has failed rather than reality. UUCP still gets used. It's one of the few sane ways to handle email in a laptop environment when you're always connecting through different dialups/ISPs. It has mostly fallen out of favour due to ignorance and FUD. Which is a shame, as it can still be a useful tool in certain situations. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> The convention was to use ``uucp'' as the default anonymous login > service. I think we're talking about two different things. Yes, many UNIX distributions shipped with a passwordless 'uucp' account with uucico as the shell. My comments about the 'nuucp' convention were referring to the publically visible anonymous UUCP sites. > Some people had the mistaken impression that there was some > sort of "hole" in the uucp system which was caused by using uucp as a > default login for uucp service. No such hole existed in modern uucico > processes, although there were bugs in early uucico (7th Edition > vintage) which may be the reason that these rumors started. I think much of this was related to the System V (R0 and R1) getty/login environment, where you could pass in arbitrary environment variables along with the login id. If your machine was poorly configured this could be used to bypass restricted shell environments. I can see where uucico shells could get lumped in with the rsh (the shell, not the network utility) environment bugs. Early uucico's were definately buggy, however I don't recall these bugs ever being exploited to compromise security. (Well, you could do DOS attacks by getting the remote uucico to drop core, leaving a LCK..site file lying around. SCO's uucico could be made to do this just by making faces at it.) > With the HoneyDanBer uucp, there were no > security holes in uucico and it was completely safe to use uucp as an > anonymous login service. I wouldn't be that absolute. No security holes were ever demonstrated, which isn't the same as saying they weren't there. (Did anyone ever breach ihnp4?) > That said, for max security it is always useful to have each site have > its own login, up to a point. Some large uucp sites used to use common > logins simply because there was so little security risk (especially with > HoneyDanBer variety). Unique logins provided fine-grained policy control. If site foo started doing bad things (deliberately or by accident) you want to be able to knock it down without taking out other functioning sites. HDB's ability to require a particular UUCP node to connect only with a specific login id was a very nice feature. (Or was it Taylor that introduced that? My memory is getting a wee bit fuzzy.) > Certainly, anonymous uucp is more secure than > anonymous ftp. For the server. The client side of the copy could definately use some work. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
All these "solutions" assume that everyone is wired up with IP connectivity. The original questions was "who uses UUCP?" One answer is: "those without IP connectivity." Part of the problem here I suspect is that the people who develop and maintain FreeBSD live a life where a T-3 into your livingroom is just something you take for granted. These folks need to spend some time living in the Northwest Territories or Central America (where IP connectivity is not just a luxury -- it's often not available) to really appreciate the ramifications of the decision to remove this software. UUCP has many valid uses. Even today. If you don't understand the software, that's fine with me. Just don't use your ignorance as an excuse to dike the software out. Or more precisely, admit you want to rip the code out because you don't understand what it is, rather than making up specious excuses for it's removal. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> Do you mean 'full-time IP connectivity', because if you can setup a UUCP > connection, you can just as easily setup a PPP connection over the same > medium, giving you IP connectivity. True, but there's a lot more infrastructure overhead involved in setting up a group of disconnected machines via dialup IP than there is connecting them via UUCP. And where dialup time is precious UUCP is the hands-down winner for not wasting any of that dialup resource. > therefore doesn't belong in the mainstream release. It *is* still > available as an add-on port, so those who need it can still get it So the base distribution contains /bin/sh, /sbin/init, and /sbin/pkg_add? Me, I like my bikesheds painted in white and green zebra stripes. > Finally, the security > issues make it a non-starter to keep in the default distribution. I would like to see evidence of where --config is *required* to make someone's UUCP setup work. And what percentage of the overall UUCP user population are represented by those people? I still contend the "problem" can be fixed by removing --config. While that fix will apparently impact some people, the impact of that fix is a lot lower than ripping out UUCP altogether. --lyndon We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true. -- Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> None of those things are realproblems. I've set up the port to be > hosted on MASTER_SITE_LOCAL for now, but Lyndon's free to go and host > it wherever he likes, organise whatever community support he likes (if > theres nontrivial interest he could surely even get a freebsd.org > mailing list set up!) and the UUCP community in FreeBSD can decide the > future direction of that port. I said I would maintain it if the code remained in the base system. If UUCP is going to ports, I have a different code base (Rick Adams' 4.4 implementation) that I'm going to use (as I also mentioned to you). BTW, could someone close out PR gnu/27715? It's not applicable now that UUCP is unbundled. Also, have you talked to Greg Shapiro about the disposition of /bin/rmail? With UUCP gone, rmail should also come out of the base system. I'm not sure if it should be built as part of the freebsd-uucp port, or become a port unto itself. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> > Just like with anonymous FTP, don't make it world writable if you don't > > want the world writing to it. > > Right - that's what actually was done. > Don't install it unless you need. Oh give me a break. You do not disable anonymous FTP uploads by 'rm /usr/libexec/ftpd'. > I'm talking about the one in FreeBSD. > uux job is to setup the commands for the next site and break the > next sitename if it equals 8 letters. That's strange. For over two years I've talked hourly to a pair of UUCP sites with eight character nodenames, and it works just fine. What is the specific breakage you are seeing? > There is a big difference - they are maintained and don't contain known > security issues. Again I ask: if maintenance is an issue, why would you not even attempt to find a maintainer? > I don't get your point - what is wrong with having it a port? Well, here's one reason: 1) Remove all the network interfaces from your system (Ethernet, PPP, SL/IP, etc). 2) cd into /usr/ports and try to build UUCP. Unless you have a prepopulated /usr/ports/distfiles, it won't work. Requiring IP connectivity to bootstrap software on a machine that doesn't have IP connectivity is a non-starter. Yes, you can install from the CDROM, but there will always be cases where you can't do this (media errors, lack of CD, etc.) However my underlying argument still remains that nothing is being done to address the actual problem. I.e., people are going out of their way to see the problem NOT get fixed. There's an issue of principal at stake here, and I really don't like the precedent that is being set by this move. --lyndon Never hit a man with glasses. Hit him with a baseball bat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> What are *you* doing to address the problem? Are you stepping up as a > maintainer? Yes. If you read the list archives you will see I've done so twice in the past already. > Are you willing to fix the problems with UUCP in FreeBSD as it is Yes. > How much time are you willing to contribute? As much as it takes. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> There are many other points - some examples I know of: > The /var/spool/uucppublic which is writeable by everyone. > Usually you don't want this. Just like with anonymous FTP, don't make it world writable if you don't want the world writing to it. > Ever received a mail with an envelope like "foo bar"@company.com? > It's legal and sendmail accepts them - but rmail doesn't like the space I use rsmtp to forward mail, so that's not a problem. > uux forwarding to a site with exact 8 letters in size doesn't work. > Yes - tranditional sites are limited to 7 letters but users don't care. But you'll know on a per-site basis if it's going to work or not. If it doesn't, you work around it. Bugs in _other_ UUCP implementations are not grounds for ditching ours. > There is a port and thus packages will be build and you can install > it whenever you need it. jot, lam, colldef, lkbib, xstr, bikeshed. > If you don't need it - which is the by far most common case - you > don't want to see such a critical and unmaintained software installed. How can it be both unneeded and critical? I'll agree it's unmaintained; the fix for that is to find a maintainer. --lyndon Learn from the mistakes of others; you'll never live long enough to make them all yourself. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mergemaster niggle
> "David" == David W Chapman <[EMAIL PROTECTED]> writes: David> mergemaster only checks to see if RCSID's are different by David> default, I forget which option, but there is one to actually David> diff the two files when doing its inital compare, but the David> RCSID's would be different so I'm not sure it would help you. The real question here is: why is the RCSid changing when the file isn't? While it's not the end of the world, dealing with these noop merges gets annoying when you're updating large numbers of machines. If there's a simple fix to the problem (at the source), let's work on it. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mergemaster niggle
> "David" == David W Chapman <[EMAIL PROTECTED]> writes: David> Sometimes things get changed and then backed out to their David> original state, but you cannot keep the original RCSID I can see that happening on the head, but this also happens on stable ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
> "Andrey" == Andrey A Chernov <[EMAIL PROTECTED]> writes: Andrey> I think it is very contr-intuitive way, better action will Andrey> be "replace" if number is the same. Nonsense. This is what 'add' and 'delete' are for. Andrey> For example "ipfw delete" takes number as an argument, Andrey> what rule it suppose to delete, if the number is the same? Andrey> I.e. how can I delete specific rule if all have the same Andrey> number? Etc, etc. You can't, in which case you shouldn't use that facility. However, for those cases where you *do* want to act on a grouped set of rules, sharing rulesnumbers provides that ability. For example, I have a set of rules that count all in- and out-bound traffic to each IP address on an internal network. All of these are under a single rule number. This makes it trivial to do things like take periodic snapshots of the counters: ipfw show 2000 > $somefile; ipfw reset 2000 This takes care of 512 individual rule entries in one simple operation. Now if you want to make some useful changes to ipfw, find someone to commit the fix in bin/18550. And get rid of the needlessly verbose usage message ipfw spits out when it fails to parse a command. It would be a lot more useful if ipfw printed (only) the failed command. At least I might have a chance of seeing what the error is, instead of having the usage message cause any useful information to scroll off the console while the machine boots. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some woes about rc.conf.site
> Then why bother having rc.conf in the first place? Just wire in all > the defaults straight into /etc/rc and leave rc.conf strictly for > overriding the defaults only, and eliminate rc.conf.* entirely. Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. The configuration information stored in rc.conf is applicable to more than just /etc/rc. Splitting out the configuration into a seperate file (rc.conf) means it can be sourced by other utility scripts, such as /etc/rc.firewall. Sourcing /etc/rc to pick up config info would be a disaster. And FWIW, I'm in favour of a read-only rc.conf with machine specific overrides in rc.conf.local. rc.conf.site should vanish. --lyndon pgpkyIExEMycO.pgp Description: PGP signature
Re: adding DHCP client to src/contrib/
On 8 Feb, Jordan K. Hubbard wrote: >> These should be left has ports. > > Can't really get away with that anymore - too many people require > DHCP for very basic bootstrapping. To insert some reality into this discussion, a quick survey at the office shows: PlatformHas DHCP Irix 6.5Yes Solaris 2.5.1 No HP/UX 10.20 Yes Linux (RH 5.x) Yes AIX 4.2 Yes BSD/OS 4.0 Yes FreeBSD 2.X, 3.XNo A "yes" means "ships with the base OS." I'll also note that the ASUS motherboards I use in our servers have BOOTP in the BIOS to support net booting via the onboard Intel Pro/100 interfaces. It's time to get out of the stone age, folks. --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
DHCP bpf alternatives
An alternative to dhclient and bpf would be to add an ioctl that would force an interface to initiate a DHCP configuration. This would allow for something like: ifconfig ep0 dhcp Of course, this means moving the entire DHCP state engine into the kernel ... --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DHCP bpf alternatives
> Erm, you forgot to include the patches to do this... I'll leave that to the anti-bpf fanatics (who can also supply patches to eliminate /dev/[k]mem while they're at it). I'm quite happy seeing ISC dhclient move into /sbin. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: paranoid patches
> > Basically, it is a patch into libkvm and w, that will allow a user (with > > the exception to the super user, naturally) to only view processes or > > information belonging to him/herself. > The only problem with this is setuid binaries. The processes may have > been started by me (top, etc..), but this wouldn't allow me to monitor > the process once it's started. And, anything that can read /dev/[k]mem is free to bypass libkvm and just grovel around in the kernel memory space, anyway. --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
CardBus Support (was: support for 3Com 3C575 network controller?)
I've been trying to get some progamming doc out of TI for
the PCI1200 PCI/Cardbus bridge (used in the Dell Inspiron
7000), however they cannot seem to understand that I'm not
asking for a pre-written device driver :-(
Does anyone out there have doc for the PCI1200 (and
preferably the entire PCI12xx family) they could send me?
Or have a knowledgable contact inside TI that could send
same to me?
--lyndon
> > # CardBus cards aren't supported. Period.
> >
> > Eek, I didn't realize this was a CardBus card. :{ I quess
> > this begs the question though, is anyone working on CardBus
> > support for FreeBSD since this is the 32-bit version of
> > PCMCIA? Yes I understand they are *completely* different.
> > Just curious.
>
> No-one is actively working on it right now. I do own one of the cards and
> it should be possible to use the existing xl driver without too many
> changes after the initial cardbus hurdle is dealt with. Paid work is
> monopolising my time right now, so I don't expect to play with it anytime
> soon.
pgpvoPagvq2Y4.pgp
Description: PGP signature
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
> There are PDF and zipped PostScript data sheets for these > parts on TI's web page: > > http://www.ti.com/sc/docs/folders/analog/pci1211.html Ya, I found those by doing a search inside the TI site. The problem is the data sheets those URLs point to only describe the hardware side of things. There's nothing there describing how to deal with the chips in software. --lyndon pgptTMuiD0TJK.pgp Description: PGP signature
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
> While CardBus isn't supported, this controller (in my Fujitsu Lifebook 280dx) > works with PAO because the PCI<->CardBus bridge supposedly uses some kind > of Intel-compatible mode. I've been unable to get it to work under stock > pccard without PAO (look at my post to -hackers yesterday), but it worked > with PAO without a hitch. I looked at PAO, but it doesn't appear to support the 3.X branch, which I'm running. If there's a PAO for 3.X, please let me know where it is (!). --lyndon pgpmCSF1Mm2La.pgp Description: PGP signature
PCI-1220 doc's found
I finally managed to extract a copy of the PCI-1220 chip documentation from TI. If anyone needs a copy of this, e-mail me and I'll forward it along. (Beware, it's a 3.5 MB PDF.) (If I get the okay from TI I'll also put it up for FTP someplace.) --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
PCI-1220 doc URL
It's online now at: ftp://ftp.execmail.ca/pub/staff/lyndon/misc/PCI1220.pdf --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Shared object "libintl.so.4" not found
> I recently upgraded one of my machines to 5.1-current, and for some reason I keep > getting "Share object 'libintl.so.4' not found" errors when I attempt to install > from ports or execute certain commands/programs. I read that upgrading my version of > gettext would fix the issue, but it has not. Is there any other way to get this > object? The simple fix: 1) teach your MUA to insert line breaks at reasonable places, and 2) ln /usr/lib/libintl.so.4 /usr/lib/libintl.so.5 --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
--On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn <[EMAIL PROTECTED]> wrote: have a: chflags ldcache /bin/sh Shouldn't that be 'chmod +t /bin/sh' ??? --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
--On Thursday, November 20, 2003 9:40 PM -0500 Richard Coleman <[EMAIL PROTECTED]> wrote: ust put a tiny termcap file in /rescue (i.e. termcap.rescue) that contains 5 or 6 of the most common terminal types (cons25, vt102, etc), and have /rescue/vi default to cons25. If you are hosed enough to require /rescue/sh then you are pretty much by definition running in single user mode. Your console options at this point are local (cons25) or the serial port (most likely vt100 or xterm), so those three will cover >99% of the cases. Anyone with a Hazeltine 1500 or adm3a serial console will already know how to use ed(1). --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Our aging base system krb5 [heimdal]
(And yes, this is a bit of an irony considering that I used to be the maintainer of the base-system Kerberos code in the long-ago krb4 days. But my job requires me to administer MIT Kerberos, so I need the MIT kadmin utility and not the Heimdal one.) Aren't the reasons for the Heimdal distribution moot these days? Beyond that, Free is one of the few UNIXen I cannot talk to (or from!) using Kerberos for things like SSH, rlogin, rdist, etc. We're woefully behind Solaris, Linux, even Windows, when it comes to integrated GSSAPI/K5 SSO authentication. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Our aging base system krb5 [heimdal]
... and it's not going to get any better till someone steps up and volunteers to improve it. Can we count on you? I've brought this up at least three times over the past 10(+?) years, and been blown off every time. So yes, I'm volunteering, again. Can I count on you? --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Do we still need portmap(8)?
> "M" == M Warner Losh <[EMAIL PROTECTED]> writes: M> I think that we need a mtree.obsolete that goes through and M> deletes these sorts of things as part of installworld/upgrade M> scripts. No solution like this will ever work for everyone, or in every situation. For example, you generally want to nuke stale bits from /usr/include, but doing the same in /usr/lib can lead to Interesting Times. And you never know if I might be working on replacements for obsoleted bits of the OS that I'm installing into their old location. For example: adduser. Current would remove it in your scenario, even though I've re-implemented it in it's old location in my build/install tree. Yes, I could modify mtree.obsolete under /usr/src, but that seems counter-productive for a -current environment. (Thankfully, I don't own a bike, so I don't need to worry about the colour of it's shed.) One compromise is to have the 'install' target touch a timestamp file before setting off to overwrite things. Then you can use 'find ! -newer ...' to search for and display possibly stale files. (A /usr/sbin/findstale script that wraps this might be a useful adjunct to mergemaster.) I use /bin/cat as a timestamp file for rough analysis purposes. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
Danny> And a list of files to delete would have saved many emails Danny> about the GCC being broken when the old headers just needed Danny> to be deleted. We could add 'rm -rf /usr/include/*' at a suitable point inside the installworld target. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
Garance A Drosihn writes: >>We could add 'rm -rf /usr/include/*' at a suitable point inside >>the installworld target. > >Installers should not be blindly removing entire directory structures. The only things that live under /usr/include are those owned by the system's install target, therefore it can do what it likes with that part of the tree. /usr/include should never contain files that do not correspond to the system's current build environment, and any files pertaining to the current build environment will be installed by the install target. There's no conflict here; anything that stops working after a "make install" scrubs /usr/include is itself broken. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is user uucp good for?
>> Maybe future generations will wonder what it is named after >> similarly to GCOS field in passwd today :-) > >At the very least we should change the shell. But Kris' suggestions >sound the best. I agree. But more importantly, let's make sure that we don't, by removing the uucp login, make it difficult for people to continue to run programs that need dialer access. If we remove uucp from the password file we need to ensure that UUCP, installed from the ports tree, will continue to work with the new device ownerships and permissions. In theory Taylor UUCP will work with only 'dialer' group access to the tty* and cua* devices, but this does need to be verified before nuking the uucp password file entry. OTOH, I don't see a pressing need to nuke the uucp login. Nothing breaks by leaving it in place, and third-party code assumes it exists (things that want to mess with modems, like FAX software). It makes more sense to (perhaps) mention 'uucp' is a deprecated login, but until *BSD defines an "official" interface to the dialer devices, it would be premature to remove the existing de-facto interface to them (think /var/spool/lock, and uu_lock(3)). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_user.c change for samba (& perl scripts!)
>>I can't find any shell script 'adduser' in >>http://www.freebsd.org/cgi/cvsweb.cgi/ >>Where can I find it? I'm not sure about the one Terry (?) mentioned, but I have a shell replacement for adduser that's 98% complete. There's one remaining bug. I wasn't going to say anything until I had rmuser done as well (it's not, yet). If people are interested I clean up the adduser part and put it up for FTP. (FWIW, my version front-ends pw, and takes it's policy from pw.conf.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Adding a 'bpf' group for /dev/bpf*
For the benefit of packet sniffers and other things that only want read-only access to /dev/bpf*, what do people think of adding a 'bpf' group for those programs? This allows bpf devices to be read by programs running with an effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes: Crist> I do this a lot too on systems where it makes sense. But I'm Crist> not sure I understand what you are asking to be done. Is it Crist> asking too much of an administrator to do, There are two ways to handle this. One is to modify the ports builds to conditionally create a 'bpf' group. This requires the ports all agree on the group, and I don't like the idea of a port install messing with permissions and ownerships of things in /dev (which aren't sticky across reboots, anyway). If the OS sets the access policy there cannot be any confusion. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> OK. Now you've really lost me. What do ports have to do with
Crist> this? Which ports? None of the sniffing programs I am aware
Crist> of use set{g,u}id bits. They rely on the permissions of the
Crist> user running them.
Sorry -- keyboard and brain disconnect on my part. What I was trying to
get at was the need to run sniffers as root by default. The fewer
things that need to be run as root, the better (e.g. I don't want snort
and trafdump running as root on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps and top.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
> "Garance" == Garance A Drosihn <[EMAIL PROTECTED]> writes: Garance> I agree. That's why a redirector makes more sense, because Garance> the redirector can be part of the base-system, and the port Garance> can be installed in /usr/local. There is one problem with the /usr/bin/perl redirector: it can cause autoconfiguration scripts to mistakenly think perl is installed on the system (they find the /usr/bin/perl wrapper) when it isn't (there is no perl-from-ports backing the redirector). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
> "Jonathan" == Jonathan Perkin <[EMAIL PROTECTED]> writes: Jonathan> An auto-configuration script which merely checks for the Jonathan> existance of a file rather than actually testing it's the Jonathan> file it needs is a bit silly and probably deserves the Jonathan> breakage. And just what else besides Perl would you expect to find in /usr/bin/perl you silly pedant?!? ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __FreeBSD_version bump for loss of perl
> "Ade" == Ade Lovett <[EMAIL PROTECTED]> writes:
Ade> Because not everyone using the ports system has the in-place
Ade> editing feature of sed that was recently added, and thus it
Ade> needs to be conditional on ${OSVERSION}.
Why can't we use ed for in-place edits?
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: __FreeBSD_version bump for loss of perl
>perl -pi.hold -e 's/FOO/BAR/g' ${WRKSRC}/a/b/{X,Y}
> is not as easy to do with `ed'.
It's not *that* hard. 10 lines of shell script is preferable to
XX MB of perl bloat. Especially for this sort of problem.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DigitalOcean offers VMs with FreeBSD!
Beware that they (DO) do not at all grok ipv6. They hand out /124s, or something equally silly. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: What to do about RCS/OpenRCS
On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What to do about RCS/OpenRCS
On May 9, 2015, at 8:05 AM, Pedro Giffuni wrote: > We do that with GNU code anyways. The latest (GPLv3) version > of RCS has already diverged and is incompatible for some third > party software so we basically ran out of support from upstream. > OpenRCS has it's own share of problems but generally we can work > with the OpenBSD maintainers to get things to improve. But really, how often does the RCS code change? This is a piece of software you get running once, and then leave alone. The last thing we want is for it to start growing "features" :-P There seems to be an ever-increasing paranoia about adopting code in the base. Are we going to end up at the point where /usr/src/ is nothing but a bunch of Makefiles with VPATH pointed at /usr/src/contrib? I get it for large outside components that are moving targets (e.g. llvm). But RCS? I think the paranoia might be a bit overdone in this case. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Depreciate and remove gbde
On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > The thing I like most about encryption is that when I RMA a bad > drive, I don't have to worry about my data leaking if I am unable > to overwrite all the data... You are optimistic if you believe that. We ($WORK) factor the cost of DOA/warranty drives into our operational budget. They never get RMAed. We drill them when they die. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] packaging the base system with pkg(8)
On 2016-04-18 5:09 PM, Nathan Whitehorn wrote: I'm not so sure about these statements. Maintaining groups of packages can be easier, but it can be also be harder. The goal is to find the right level. And I haven't seen a case where an 800-packages level of granularity is helpful. Not to mention regression testing. The number of combinations of installed packages is going to be choose(1, 800) + chose(2, 800) + ... + choose(800, 800). And while some of those combinations will be non-nonsensical, many(!) won't. There aren't enough seconds in the universe to test all the viable combinations for one single release. If fact, I would suggest a good metric for package granularity be based on the set of combinations that *can* be tested in a realistic timeframe for each release. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 2016-04-18 7:01 PM, Roger Marquis wrote: Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports. The ports tree isn't a mandatory part of the system. And by definition it could not be tested that way, since it offers so many alternative implementations of specific functionality. Other operating systems don't do that for their base packages. I'm pretty sure Solaris had some fairly hard-core regression tests to ensure basic system functionality wouldn't be compromised by 'oddball' selections of packages offered up at install time. > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. The concern is from all of us UNIX dinosaurs who predate the fine-grained packaging environment, which just worked, and who now rip our (little remaining) hair out due to unsolvable package dependency loops in the Linux machines we are forced to administer in order to pay rent. For me, as a sysadmin, I derive a negative benefit from this optimization. I guess what I'm really asking is: where is the peer reviewed research that shows this actually improves things for the not-1% of FreeBSD users? --lyndon P.S. Don't turn this into a pissing match. I really want to know how this is of net benefit to everyone. But I don't want hyperbole. I have looked at a lot of, e.g., USENIX and ACM, bibliographies and papers for justification for this, and I can't find it. It would really help (me, at least) if someone could take a moment to point me at demonstrable evidence of the benefits of this model. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 2016-04-18 8:17 PM, Alfred Perlstein wrote: Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted to make it less granular all they would have to do is make some meta-packages. It's the *I have to put it back together* part that's annoying. I didn't break something that has worked, forever. It shouldn't be incumbent on me to un-break someone else's work. Now if the system ships with each-file-in-a-package, fine. Just give me gross subsets that make my life as a sysadmin liveable. E.g., base POSIX functionality should be a 'group' package. And I would hope, the default installation package. I would go for the argument that, e.g., the dev stuff (cc, yacc, lex) could be split off, but at least include the headers that match what's in /lib and /usr/lib, in a compiler agnostic set. Since the point of packages is to allow for selections of optional software. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. True enough. But I am also wary of decending into what became of X, where a build of the xorg metapackage spends 80% of its time running configure, over and over and over again. How long until a source build becomes a series of 'rpmbuild ...' equivalents? Sadly, if this level of fine grained packaging infects the base, it *will* only be a matter of time ... So no matter what the good intentions, this is going to impact everyone, like it or not. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016, Warner Losh wrote: Sadly the tenor and tone of the discussion isn?t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. I agree. Really, I do! But this must work both ways, and I can say unequivocally that my earlier interactions with the 'pkg' people have been unpleasant. Some time ago I asked about how pkg interacts with LOCALBASE!=/usr/local. This because I like to build ports from /usr/ports, but install them under /usr/pkg so as to keep /usr/local free for truly local code. This works fine (after a source rebuild of pkg), but for tools like portupgrade (from ports), which use pkg under the hood to handle dependency checks. pkg against the ports tree vs. pkg against my LOCALBASE=/usr/pkg were conflicting. So I asked some questions about how to resolve this. The response was bizarre. Wanting to use pkg with a different directory seemed almost offensive to the peoploe who answered. There was no thought of even considering the use case. I ended up filing a bugzilla report, but I see that got close with 'works as intended' a couple of days ago. I can't see how pkg as a base package manager would allow me to continue with my ports->/usr/pkg mapping. I really think the biggest problem people have at the moment is the complete and utter lack of respect core and the pkg crew have for the end users of the system. I'm pretty sure we all get WHY this work is being done. We don't all AGREE with why it's being done. And that is the conversation we are trying to have. But every time we try to have it, we get slammed down as a bunch of ungrateful whining non-coders. Lots of people wrote a lot of lines of code for Linux. Is the argument that we should just adopt that? Because it's written, it must be good? You guys need to get over that and come back to the table to have a rational discussion with the vast majority of people who actually USE this OS. All glory to Juniper and Citrix and everyone else who packages the OS into their various 'appliances'. I use both of the above at work, and believe me, for the amount of money they take out of my pocket, they can hire their own release engineers to deal with this internally without inflicting this on everyone else. And I really think THAT is the crux of the argument everyone is trying to make. To reiterate: packages are good. In moderation. As with all other things. But they have to solve the general case, and pkg - both the tool and the methodology in its current and pending incarnations - does not. I, and others, are trying to have a real conversation about this. But the blowback is incredible. Let alone incredulous. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
why 100 packages are evil
Here's a real example. I have n Centos servers. Cron, once or twice a day, updates our local cache of the yum repos. Then nagios comes along and flags 35 packages out of date. An hour later, management comes along asking questions about the security implications of those packages. An hour later we finish trolling through and say 'no worries'. Repeat. Every day. With freebsd-update, an announcement comes out that says 'update'!. So we do. Move from 10.2-p11 to 10.2-p12. There is a very clear track record of why and how this happened. What will be the new update frequency with >100 base packages? How will that impact people running productions systems. I know rebooting the mysql servers is an amount of pain that everyone below the VP level doesn't want to have anything to do with it; explaining to the VP that is. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why 100 packages are evil
Same as it is now for releases. Packages will be available for SAs/ENs. There is no intention to change this model. I get that. But the dependency base will be huge. Right now I can count on a very limited set of dependencies for anything I ship as a 3rd party package. Doing that for n>100 packages gets to be troubling. I know it can be done, but for a small company like the one I work for, it quickly becomes impractical. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of catman from base
That was actually not why catman was brought into the world: ATT/USL thought text-processing was The Goods so they unbundled it base SVR and invented catman to make up for the missing nroff. Not quite. They (AT&T) sold the rights to sell typeset manuals to some publishing house (I forget which), at which point they stopped shipping the *roff source for the manpages on the source tapes. Instead, you got pre-formatted "cat" pages on the source tape. I think this happened starting with SVR3. catman(1) was always about doing bulk nroff runs against the whole of /usr/man, because, back in the day, running nroff on demand was slow. Even on a 785. (catman without nroff would have been a no-op.) --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of catman from base
On Tue, 12 Sep 2017, Poul-Henning Kamp wrote: I'm pretty sure that SVR1 had catman and roff was an extra and somewhat pricey software package. The SVR1 (and 2) systems I had access to were all CTIX, and it shipped with nroff/troff. And the 3B4000 & 3B2s I used later (SVR2 and later) also had nroff/troff. Maybe you're thinking of ditroff (Device Independent Troff) that was sold for gobs of $$$ through the AT&T Toolchest. Certainly none of the SVRx machines I used shipped with ditroff. I don't even think ditroff was on our 3B2 SVR3 source tapes. But I very clearly recall the absense of manpage source on that SVR3 tape. I remember howling bloody murder at AT&T Canada over that. This was at Athabasca University - a distance education institution. We typeset all our own course materials (using Softquad's sqtroff), and not being able to include properly typeset manpages with the course documentation (especially reflecting our local modifications to the systems) made me ... grumpy. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
Methinks your $TERM is set incorrectly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Max, I think a reasonable default is to continue building and shipping profiled libraries. This keeps FreeBSD consistent with every other UNIX variant released in the last (at least) 30 years. If you personally find profiled library builds slow you down too much, a one line addition to your /etc/src.conf solves the problem for you. Personally, I find building kernel modules to be intolerably slow, since I tend to run static linked kernels. I dealt with my preference by adding one line to my /etc/src.conf, not by submitting a patch request to disable the functionality in the builds. If you choose not to profile your code, that's entirely your choice. Breaking this functionality for everyone else who *does* make the effort to profile their code is a non-starter. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Nothing is being broken here, just a default being changed. Users make up a greater proportion of our userbase than developers, so sensible defaults for them are more appropriate, right? This has no impact on non-developer end-users. For "developer" end-users, this has a huge impact. You are forcing each and every developer who wants to profile their code to modify their /etc/src.conf and then 'make buildworld' solely because Max can't be bothered to add one line to his own /etc/src.conf. Developers who profile their code makes up a greater proportion of our userbase than 'Max', so sensible defaults for them are more appropriate, right? --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Something else I forgot to mention ... The point of -CURRENT is to make sure everything works before it becomes -STABLE and -RELEASE. Not building significant components of the system ensures those components don't get tested. This includes the actual build process, as well as the underlying profiling functionality. As a FreeBSD developer, you eat the cost of compiling everything. As a FreeBSD developer, if you are concentrating on a specific area at a particular time, turning off un-related parts of the build might speed things up for you. As a FreeBSD developer, you know how to do that. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Using profiled libs and gprof to profile your code has been obsolete in FreeBSD on i386 and amd64 for over six years now. Funny, it still seems to work on my systems. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Obsolete does not mean it doesn't work. No, these days 'obsolete' seems to mean 'it does not have a sexy Flash-driven web GUI.' Profiling is a simple basic tool that makes it easy to quickly find code execution hot-spots. It's not dtrace, or any other plethora of tools that do a more extensive job of profiling. But it's also a tool that is universally available to developers. Or was ... If you don't like it, don't use it. But don't turn that into an excuse to remove the functionality from the rest of us. If you really think profiling is truly useless in this day and age, the proposal should be to eradicate it from the system entirely. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
In this case, 'obsolete' means it's a difficult-to-use tool that requires recompiling your application, can't be used in production, doesn't work when shared libraries are in the picture, offers limited-to-no visibility into the underlying reasons why a particular code path is a hotspot and introduces large measurement errors No, it just means it doesn't work for you. It does work for me, though. And for many others. Many a time I have shipped a profiled binary off to a customer site to determine where they are having performance problems. This works because they don't need to install any third-party tools or jump through other hoops. It's not perfect, but it is a useful debugging tool. The arguments I keep hearing here are "I don't (understand how to effectively) use this tool, therefore it should be removed." Collectively that argument can be applied to each and every component of FreeBSD when taken across the entire user base. Thus we can infinately optimize the builds though 'rm -rf /usr/src'. Now can we please just leave WITHOUT_PROFILE alone and go fix real bugs? If it will help, I will toss in a few hundred bucks to help Max buy a faster build machine. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Isn't this about user choice, and making sensible defaults? There are two or three "users" out of thousands complaining about the default. If the extra build time bugs you that much, I'll contribute towards buying you better build hardware, too. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Sparc build boxes
Speaking of throwing hardware at people, I have a couple of Sun V100s that could go to a good home for FreeBSD Sparc development purposes. They come equipped with 1GB of RAM and a pair of 80GB disks. If anyone can make a legitimate case for them, drop me a note. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Sparc V100s (re donations)
About the donations page et al ... that's set up for cash donations. Hardware doesn't go through there very well. I don't care about tax receipts. I'd rather just send the gear directly to any people who can legitimately use it (i.e. someone with an @freebsd.org address, or someone with an @freebsd friend who will vouch for them). I will pay for any reasonable shipping charges. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rcs is gone?
I know I am a certified crank, but ... why? This is some of the simplest code on the planet. Is it broken by recent OS releases? I use ci/co every single day to track changes to individual config files on individual machines. For simple things like ntp.conf, rc.conf, sysctl.conf, a simple 'ci -l xxx' is a trivial way to maintain local revision control. For small stand-alone systems, RCS is more than adequate. Why ditch it? --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 2:02 PM, Lyndon Nerenberg wrote: > I use ci/co every single day to track changes to individual config files on > individual machines. For simple things like ntp.conf, rc.conf, sysctl.conf, > a simple 'ci -l xxx' is a trivial way to maintain local revision control. And sorry, what I left out was how having ci/co in the base is immensely helpful with the installer scripts I write. The server installation scripts I've cooked up use ci(1) to keep a record of changes made during the (possibly customized) installation process. This is impossible if there isn't a basic RCS in the base system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 2:08 PM, Lyndon Nerenberg wrote: > And sorry, what I left out was how having ci/co in the base is immensely > helpful with the installer scripts I write. The server installation scripts > I've cooked up use ci(1) to keep a record of changes made during the > (possibly customized) installation process. This is impossible if there > isn't a basic RCS in the base system. Finally, an issue with missing SCCS in the base is for those of us who work in shops behind an air-gapped firewall. "Install from ports" is a non-starter. Our development systems will never be connected to the internet for a ports upgrade. In this environment, in-base RCS is a very useful tool. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 2:53 PM, David Chisnall wrote: > Or do you really only run the base OS and no other software on your systems, > without any of your own code or any customisation? We install from the base release ISO images burned on DVDs. We are physically air-gapped from the internet, none of the "end users" of the system have access to USB ports, and there are no electronic devices allowed into the development shop. We have a scheme for bringing in software from /usr/ports, but it is painful. And those ports can't necessarily walk on to all the systems in the shop. (I don't make the rules. Suffice to say the company is very paranoid about their code getting out into the wild.) Having RCS in the base system is very useful. We use it to track changes to bits of /etc on the machines where we don't do wholesale customizations. (Those ones get git, but they also get an install of /usr/ports with a fully populated /usr/ports/distfiles.) So if nuking RCS is a case of "I don't use it," ... we do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 3:45 PM, Lyndon Nerenberg wrote: > Having RCS in the base system is very useful. We use it to track changes to > bits of /etc on the machines where we don't do wholesale customizations. > (Those ones get git, but they also get an install of /usr/ports with a fully > populated /usr/ports/distfiles.) To clarify, the git-enabled machines are a small isolated subset of the development machines. Then comes the test and q/a environment, where we (by contract) roll nothing beyond the base OS and our application software. There are other development shops dealing with the same restrictions. Most of them have to stay quiet about these requirements on account of the Homeland Security. They are all getting buggered over by the fallacy that everyone has a gigabit ethernet connection permanently wired into their ass ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 4:37 PM, Adrian Chadd wrote: > Then you and others should stand up and provide feedback like this far, far > earlier in the development process. So when was this first discussed? I've been on -current for over a decade. If I missed a prior discussion I truly apologize. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 4:49 PM, Adrian Chadd wrote: > I've asked on IRC to figure out when this was first proposed. Adrian, something to keep in mind is that the majority of your code's users will never use your preferred communication media. So when you propose to remove a feature, absence of push-back means nothing, other than the lack of a communications channel with your 'customers'. We get this a lot with feature manipulation in nmh, and have learned to tread carefully as a result. This is also why the IETF defines work as being that which takes place on the mailing lists. Slow and dumb (in the media-rich sense), but everyone knows what's going on. In that light, if there is a rational argument for pulling RCS out of the base, propose it here on the -current list and let's all discuss it. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 5:40 PM, Julian Elischer wrote: >> svnlite? >> > fail I won't go that far, immediately. But I need a tool that lets me migrate the history of my RCS files to the new regime. And the new tools(s) *must* be part of the base system. (Migration tools included.) And the new scheme should provide something as simple as 'ci -l foo'. I'm not convinced svn does that. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 5:58 PM, Ian Lepore wrote: > I have not re-read those threads to see just how much of the discussion > involved rcs, I just spot-checked a few and confirmed my memory that it > showed up in some of the messages there. I don't see any discussion as to why the code (CVS, in this case) *needs* to be removed. What, in the current builds of 10.x, is broken by leaving RCS/CVS in place? And what, as 10.x moves forward towards a public release, will be broken by leaving this code in the base? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs is gone?
On 2013-10-07, at 6:05 PM, Lyndon Nerenberg wrote: > I don't see any discussion as to why the code (CVS, in this case) *needs* to > be removed. My stupidity: I meant RCS, not CVS. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rcs
Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On 2013-10-07, at 8:15 PM, Steve Kargl wrote: > Maybe there was no development for 15 years. However, the 7364 > lines in ChangeLog after 2010-02-04 suggests that there may > be few bugs to worry about. Dear Troll, Demonstrate one. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On 2013-10-08, at 11:17 AM, Freddie Cash wrote: > I haven't kept up-to-date with all the developments, but isn't this part of > the bsdinstall/pkgng plan? Once the pkgng repos are all available and > populated, then bsdinstall will be able to install packages from there during > the install. And, isn't that part of the plan for the DVD installers, to > include an "installer repo" for off-line installs? > > IOW, theoretically, one could just download the 10.0 DVD, boot, install the > base, browse the repo on the DVD, select items to install, install, reboot, > and be finished. Without ever needing to touch an Internet connection until > after rebooting into FreeBSD, if it's even needed at all. The big issue here is having access to the distfiles. We rarely, if ever, install pre-compiled packages, because we don't know how they have been configured. Quite often the packages are built with features or dependencies we don't want, or are built without features we *do* want. Instead, we configure and compile the port according to our requirements, then build a package from that for internal use. For this to work in a disconnected environment, you need a ports tree with a fully populated distfiles/ directory. The hack we came up with was to put a FreeBSD host on the external network, on which we ran a script once a week or so that would do the something like 'portsnap fetch update; portsclean -DD; for in in /usr/ports/*/*; (cd $i && make fetch); done'. That would give us a (mostly) populated /usr/ports/distfiles. We would then rsync /usr/ports from the public machine onto a USB drive. That drive would then be disconnected from the public machine and attached to an internal file server, and its /usr/ports rsynced to the file server's /usr/ports. Not pretty, but it got the job done. But that /usr/ports tree is way too big to fit on a DVD. In fact, it might even be too large for a BD-ROM. (I don't have access to the file server right now to check.) --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rcs
On 2013-10-10, at 1:06 PM, Igor Mozolevsky wrote: > You're missing the point- the requirement is "provide a way to keep track > of changes for file X" not "have many fancy and unnecessary features"... The point is to put back the specific RCS commands that were recently removed. Those of us using RCS do so because it's in the base system. If we wanted/needed another SCM, we would install it from ports. But many of us use RCS specifically because installing a port is not an option. *Why* it's not an option is not relevant. RCS is not broken, and is very low maintenance code. /usr/src/gnu/usr.bin/rcs has been modified four times in the last decade. Two of those changes were sweeping Makefile updates that affected much more than RCS. Of the other two, only one update touched the actual code, and that was a one line change to a .h. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 and zfsd
On 2013-10-10, at 2:54 PM, Allan Jude wrote: > I've been working on the handbook section on ZFS and made certain to > mention that, I'll have to look at improving the man page as well, but > as far as I know, the man page is imported from IllumOS, where spares do > work. This is probably worthy of an in-tree man page update. FreeBSD has a reputation for having highly accurate man pages, therefore people tend to take what they read as gospel. Right now zpool(8) clearly spells out that hot spare substitution works. When 10.0 goes live, people are going to believe that, and unknowingly put themselves in a position where Bad Things could happen. Until zfsd goes into the tree, zpool(8) should have a warning that the hot spare functionality is not available under FreeBSD. Proposed diff attached. --lyndon Index: zpool.8 === --- zpool.8 (revision 255198) +++ zpool.8 (working copy) @@ -283,6 +283,7 @@ For more information, see the .Qq Sx Hot Spares section. +.Sy "(The hot spare functionality is not currently implemented on FreeBSD.)" .It Sy log A separate-intent log device. If more than one log device is specified, then writes are load-balanced between devices. Log devices can be mirrored. However, @@ -425,6 +426,8 @@ attempts to put the device online automatically. Device attach detection is hardware-dependent and might not be supported on all platforms. .Ss Hot Spares +.Sy "(The hot spare functionality is not currently implemented on FreeBSD.)" +.Pp .Tn ZFS allows devices to be associated with pools as .Qq hot spares . @@ -1946,3 +1949,6 @@ .Xr mdoc 7 implementation of this manual page was initially written by .An Martin Matuska Aq m...@freebsd.org . +.Sh BUGS +Hot spare substitution awaits the import of +.Xr zfsd 8 . ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
> Support for a cron.d directory is a tool that can be > used in many ways. I have used cron.d on other UNIXen, and for package-installed cron jobs I find it significantly friendlier, in that it makes these jobs easily identifiable to the sysadmin. As we do it now, the per-user crontabs are quite opaque. It's easy to get a list of the 'logins' that have them, but the best you can do is cat the files and hope the entries are well documented or obvious from context. And editing a single file from an installer script is always subject to failure: it's hard to guard from failure if somebody comes along and, in the course of manually editing the file, upsets the markers the [un]installer scripts are looking for. Allowing a package to add/rm a self-contained file avoids these accidental editing muckups. And with a simple standardized naming convention, the mapping from cron files to packages can be both unique and obvious. This is a big win for the sysadmin trying to track down a mystery run-away cron job. Some attention must be given to setting things the uid/gid to run under, and it might be useful to allow specification of things like the login class, and perhaps capsicum capabilities. Actually, the latter two features are useful in the general case. Regardless, the core idea is both sound and useful. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala wrote: > What's wrong with using the existing tools for achieving the same > effect? Periodic can be adapted to do exactly what you're describing > as noted above by adding an hourly (even minutely? :D ) periodic run. Periodic is geared towards periodic system maintenance tasks. Once per day, once per week, once per month. It doesn't deal with tasks that need to be fired off at arbitrary intervals. As you say, it could be adapted to run things with per-minute granularity, but it wouldn't scale well. For per-minute granularity you would have to fire off a periodic run every minute. That's five times the rate that atrun(8) kicks off at. That's a lot of overhead for small, embedded, or power constrained systems. And to get the time-granularity cron has, you would have to re-implement cron(8)s dispatch control as a set of shell functions. That's just silly. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Nov 7, 2013, at 9:13, Allan Jude wrote:
> Right. The best way to handle this is likely to have the ports install
> the example cron to ${PREFIX}/share/portname/ or wherever else they
> normally put examples, with instructions in the pkg-message on how to
> enable the cron. The same way that ports that add something to apache
> don't install to the apache etc/apache22/Includes/ directory, but
> instead tell you to add the lines to a file there.
It’s probably better to have the port’s rc.d script verify the crontab is in
place, and install it if it’s not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Nov 7, 2013, at 19:41, Allan Jude wrote: > it really depends on the port and what the cron > is doing. Why? Can you give some specific examples? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Nov 7, 2013, at 19:46, Kimmo Paasiala wrote: > I don't like the idea of having untracked files installed by the rc(8) > script. Why not install the cron.d snippet by default but leave > everything in it commented out with instructions at the beginning to > uncomment the contents to enable it? It’s un-necessarily complicated. The package manifest can specify both locations for the crontab file. If the copy isn’t made, at package removal the worst that will happen is a warning diagnostic will be printed about the missing file. —lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
