Re: noatime on ufs2

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Warner Losh writes:

> > I'm really interested in hearing from people who actively use
> > atime on a regular basis for non-trivial purposes.  What are
> > the modern use cases for atime?

> The consensus was we'd fix it in the installer.

Sure, but my question still stands.  I'm genuinely curious
to know how (or if) people still use atime.

--lyndon

Re: noatime on ufs2

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

> > I do not have a strong opinion w.r.t. atime, but I do believe that
> > changing the default would be a POLA violation.

I'm not prepared to just accept that at face value.

I can't think of a single instance in at least the last three decades
where I have actually used or needed atime for *anything*.  And
over that time period I have been responsible for running hundreds
of UNIX servers.

I'm really interested in hearing from people who actively use
atime on a regular basis for non-trivial purposes.  What are
the modern use cases for atime?

--lyndon

Re: noatime on ufs2

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Olivier Certner writes:

> I've never found any compelling reason in most uses to enable "atime", except
>  perhaps local mail but as addressed in other answers it is a relic of the pa
> st mostly irrelevant today.  And its drawbacks are well known and can be seri
> ous.

When UNIX ran on PDP-11s and disk pack sizes were measured in the
tens of megabytes, atime was very helpful in determining which files
were likely candidates for archiving to tape when the disk was
getting full.  And in the Usenet days it was common to mount
/var/spool/news noatime, which eliminated a *lot* of meta-info
write traffic.

These days, other than /var/mail, I can't think of a compelling use
for it.  I've been running my Plan 9 systems with atime disabled
ever since fossil arrived (decades) without any impact.

I don't see any issue with making noatime the default.  For those
that must have it, /var/mail can be carved out as a distinct
filesystem and mounted appropriately.

--lyndon

Re: native recording of all network connections on freebsd

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Dan Mack writes:

> I'm wondering if anyone can help point me at a good way to continously 
> capture every inbound and outbound connection made to a freebsd system. 

Assuming "connection" means "log every TCP connection setup" probably
the quickest way is to tcpdump every TCP packet with both SYN and
ACK set.  That will log one packet for every TCP connection that
is established with the system. It won't capture anything for
connection attempts that fail. If you want that as well, just log
everything with SYN set.

If you do the latter you will also collect the background noise
from people port scanning you and attempting other nefarious deeds.

--lyndon

Re: Removal of catman from base

[Lyndon Nerenberg]

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 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 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: Removal of catman from base

[Lyndon Nerenberg]

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) 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: why 100 packages are evil

[Lyndon Nerenberg]

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"

why 100 packages are evil

[Lyndon Nerenberg]

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: [CFT] packaging the base system with pkg(8)

[Lyndon Nerenberg]

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"

Re: [CFT] packaging the base system with pkg(8)

[Lyndon Nerenberg]

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)

[Lyndon Nerenberg]

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)

[Lyndon Nerenberg]

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)

[Lyndon Nerenberg]

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: Depreciate and remove gbde

[Lyndon Nerenberg]

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: What to do about RCS/OpenRCS

[Lyndon Nerenberg]

On May 9, 2015, at 8:05 AM, Pedro Giffuni p...@freebsd.org 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: What to do about RCS/OpenRCS

[Lyndon Nerenberg]

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: DigitalOcean offers VMs with FreeBSD!

[Lyndon Nerenberg]

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: shells/bash port, add a knob which symlinks to /bin/bash ?

[Lyndon Nerenberg]

On Sep 12, 2014, at 2:40 PM, Baptiste Daroussin b...@freebsd.org wrote:

 If you want interoperability just use /usr/bin/env bash as a shebang. Btw you
 cannot get interoprability with OS-X in there because the bash they do provide
 is the last GPL-2 recent bash have many incompatiblities with this old 
 version.

The concern is not with shell scripts, it's with the contents of the pw_shell 
field in 'struct passwd'.

I run into this all the time, too, but with ksh.  In my case I just cp a 
static-linked version of whatever ksh variant I happened to build into /bin/ksh 
and call it a day.  It's not like the shell source code is changing every other 
week, even for bash.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: shells/bash port, add a knob which symlinks to /bin/bash ?

[Lyndon Nerenberg]

On Sep 12, 2014, at 3:23 PM, Craig Rodrigues rodr...@freebsd.org wrote:

 Forcing all upstream script writers to switch to #!/usr/bin/env bash, or
 to convert their scripts to #!/bin/sh and remove all bash-specific
 behaviors, is getting harder and harder,
 since many people are exposed to MacOS X and Linux on desktops.

Given the rigid nature of shebangs to begin with, it's really not that hard to 
write a sed command that will capture all instances of '#!.../bash[ foo]' and 
wire in an appropriate value of '...'.

In fact, this case is a ripe candidate for a bsd.port.mk command macro.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: shells/bash port, add a knob which symlinks to /bin/bash ?

[Lyndon Nerenberg]

On Sep 12, 2014, at 3:55 PM, Bryan Drewery bdrew...@freebsd.org wrote:

 There already is one and ports requires using it!

Doh!



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Future of pf / firewall in FreeBSD ? - does it have one ?

[Lyndon Nerenberg]

On Jul 20, 2014, at 11:35 AM, Daniel Feenberg feenb...@nber.org wrote:

 Rather they have said An updated pf would not be
 suitable, as it would be incompatible with existing configuration files.

A major FreeBSD version increment is allowed to break that level of backwards 
compatibility.  Nothing prevents this from being incorporated into 11.x.

The only real concern would be removing existing core functionality as part of 
the update.  For that you want to provide at least one major release cycle for 
people up migrate.  Comparing pf on my current OpenBSD machines vs. the FreeBSD 
10.x pf, that doesn't seem to be an issue.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BSD XXI Manifesto [mDNS proposal]

[Lyndon Nerenberg]

On Feb 27, 2014, at 12:20 PM, Matthew Rezny matt...@reztek.cz wrote:

 If IPv4LL is in active use, the DHCP 
 client should continue to periodically look for a DHCP server and obtain a 
 lease without manual user intervention (which is unfortunately required on 
 both OS X and Windows, leading to sub-optimal experience in cases of 
 temporary 
 unavailability of the DHCP server).

That's not true for Mac OS.  If you have an interface configured to use DHCP, 
and the Mac is unable to renew the lease, it will automatically configure a 
169.254.x.y address on the interface.  All the while it continues its attempts 
to renew the DHCP lease and, once successful, removes the 169.254.x.y address 
from the interface.

--lyndon


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BSD XXI Manifesto [mDNS proposal]

[Lyndon Nerenberg]

On Feb 27, 2014, at 15:59, Matthew Rezny matt...@reztek.cz wrote:

 If they corrected that, it was after I abandoned the platform years ago.

It has been like that since at least 10.8.


And I am also tempted to say that Windows 7 acts the same, but I don't have one 
at hand to double check.
___
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: Import of DragonFly Mail Agent

[Lyndon Nerenberg]

On Feb 24, 2014, at 7:40 AM, Bryan Drewery bdrew...@freebsd.org wrote:

 Anything not meeting the bare-bones criteria can be installed with 'pkg
 install' or ports.

Try this in a shop where all your machines are completely air-gapped from the 
internet.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Import of DragonFly Mail Agent

[Lyndon Nerenberg]

On Feb 24, 2014, at 7:56 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 Bullshit.

Sounds like your week didn't get off to a good start.

 You got FreeBSD in there in the first place, there clearly
 is some kind of aperture through which software can migrate.

Yes, we walk in a DVD-ROM with a FreeBSD installation image on it.  This works 
because there is a self-contained installer that contains a very complete 
system.  Certainly enough to build things like file servers and network 
infrastructure machines (dhcp, ntp, other general network services).

Installing ports/pkgs, on the other hand, is a real pain.  For pre-built 
packages, you can build a list of dependencies, download the packages to an 
external machine, copy them to a portable drive, and walk them over to a shared 
filesystem.  This works, provided there are pre-built images of the package and 
its recursive dependency tree (and that they are configured in a way that works 
for your environment).

If the above doesn't work, you have to fall back to ports.  And this is where 
things get really hairy.  Just generating the list of required distfiles is 
problematic.  'make fetch-recursive-list' will give you a script to run to pull 
down the direct build dependencies, but this misses run-time dependencies.  
Generating that list takes a lot of manual work, and is *very* time consuming.

The increasing focus on securing systems from network attacks in only 
increasing the number of air-gapped environments (and I know this from first 
hand experience).  The sort of massive unbundling that a few people are tossing 
around here has the potential to exponentially increase the workload of people 
operating in the environments I have witnessed (and worked in).  I want them to 
realize that there are ramifications to those sort of changes that need to be 
taken into consideration.

These days UNIX tends to be single-user environment, for the most part.  
Because of that it is very easy for people to get into the mindset that if I 
don't use it, nobody else uses it, and thus losing sight of the whole being so 
much greater than the sum of its parts.

That said, I can understand wanting to unbundle some of the very complex but 
lesser used components (e.g. bind).  But there's always a balancing act to be 
performed here.  Making every command in /usr/bin its own package serves 
nobody.  (Yes, I exaggerate to make a point.)

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Import of DragonFly Mail Agent

[Lyndon Nerenberg]

On Feb 24, 2014, at 8:50 AM, David Chisnall thera...@freebsd.org wrote:

 Or, purely hypothetically, if your goal was to make it work, you could just 
 use Poudriere which will take a list of packages that you need and build a 
 package set for you, which you can stick on a DVD / USB stick / whatever and 
 take into your production environment.

For all the air-gapped shops I dealt with, any package builds had to be done 
inside the air-gap.  (Those were the rules - I didn't make them.)

The bottom line was: the fewer external dependencies to build a basically 
useful system, the better.

 If Poudriere doesn't do what you want, then constructive feature requests are 
 always welcome (bapt likes having us add things to his to-do list - he has 
 way too much free time).

What would really help is if the ports fetch-recursive-list target could extend 
to reliably include the distfiles for the runtime dependencies as well.  But 
I'm not even sure that's possible.  We tried a few different things, but in the 
end we had to brute force it by running 'make fetch' in every one of the ports 
directories in order to get all the distfiles onto an external system, which we 
then rsynced to a USB drive, marched inside, and rsynced to the fileserver.  
Not pretty ... but with all the distfiles at hand we knew the inside ports 
builds wouldn't fail due to missing dependencies.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: cron(8) improvement

[Lyndon Nerenberg]

On Nov 7, 2013, at 9:13, Allan Jude free...@allanjude.com 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

[Lyndon Nerenberg]

On Nov 7, 2013, at 19:41, Allan Jude free...@allanjude.com 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

[Lyndon Nerenberg]

On Nov 7, 2013, at 19:46, Kimmo Paasiala kpaas...@gmail.com 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

Re: cron(8) improvement

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com 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: rcs

[Lyndon Nerenberg]

On 2013-10-10, at 1:06 PM, Igor Mozolevsky i...@hybrid-lab.co.uk 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

[Lyndon Nerenberg]

On 2013-10-10, at 2:54 PM, Allan Jude free...@allanjude.com 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: rcs

[Lyndon Nerenberg]

On 2013-10-08, at 11:17 AM, Freddie Cash fjwc...@gmail.com 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

rcs is gone?

[Lyndon Nerenberg]

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?

[Lyndon Nerenberg]

On 2013-10-07, at 2:02 PM, Lyndon Nerenberg lyn...@orthanc.ca 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?

[Lyndon Nerenberg]

On 2013-10-07, at 2:08 PM, Lyndon Nerenberg lyn...@orthanc.ca 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?

[Lyndon Nerenberg]

On 2013-10-07, at 2:53 PM, David Chisnall thera...@freebsd.org 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?

[Lyndon Nerenberg]

On 2013-10-07, at 3:45 PM, Lyndon Nerenberg lyn...@orthanc.ca 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?

[Lyndon Nerenberg]

On 2013-10-07, at 4:37 PM, Adrian Chadd adr...@freebsd.org 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?

[Lyndon Nerenberg]

On 2013-10-07, at 4:49 PM, Adrian Chadd adr...@freebsd.org 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?

[Lyndon Nerenberg]

On 2013-10-07, at 5:40 PM, Julian Elischer jul...@freebsd.org 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?

[Lyndon Nerenberg]

On 2013-10-07, at 5:58 PM, Ian Lepore i...@freebsd.org 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?

[Lyndon Nerenberg]

On 2013-10-07, at 6:05 PM, Lyndon Nerenberg lyn...@orthanc.ca 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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

On 2013-10-07, at 8:15 PM, Steve Kargl s...@troutmask.apl.washington.edu 
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: Light humour

[Lyndon Nerenberg]

On 2013-04-29, at 8:27 PM, Teske, Devin wrote:

 http://www.youtube.com/watch?v=SXmv8quf_xM
 
 (Please, don't be drinking anything.. I disclaim all responsibility
 for keyboard damage)

Please, PLEASE, can we have a Where Are They Now segment about this kid?  I 
want to know which company he is the CTO of.  More interestingly, I want to 
meet the board of directors that hired him ;-)

___
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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

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)

[Lyndon Nerenberg]

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

Re: ee (easy editor) bugged on 9.0?

[Lyndon Nerenberg]

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: Adding disk firmware programming capability to camcontrol

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

 The linux hdparm program is so paranoid about this that you have to use 
 extra arguments like --yes-really-destroy-my-disk-drive to do this.

I concur. Loudly.  The ability to brick your hardware is just too
large to not make people go through the I tell you three times
dance.  It's not like people will do this often enough that the
pain will be fatal.  And if it is, they ought to be bright enough to
know how to automate the process.

--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]

[Lyndon Nerenberg]

(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]

[Lyndon Nerenberg]

... 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: HEADS UP: /bin and /sbin are now dynamically linked

[Lyndon Nerenberg]

--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: Unfortunate dynamic linking for everything

[Lyndon Nerenberg]

--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: Shared object libintl.so.4 not found

[Lyndon Nerenberg]

 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]

Another take on adduser

[Lyndon Nerenberg {VE6BBM}]

A couple of months ago I wrote a shell implementation of adduser.
One of the things that bothered me about the old version was the
way its policy and configuration pretty much duplicated that of pw(8).
Being able to set inconsistent policy like this is not good. Also,
pw already implemented all of the functionality adduser required, so
why reinvent this?

My adduser simply presents a (somewhat) user-friendly front end to
pw. It prompts for the data, does some very simple validation on it,
then invokes pw to do the real work. It reads policy information from
pw.conf rather than having its own configuration file, and it takes no
command line arguments what so ever. (If you're smart enough to start
specifying the types of arguments the old adduser supported, you're
smart enough to just use pw. Ditto with the batch functionality.)

If anyone is interested in exploring an alternative implementation, the
code is at ftp://orthanc.ab.ca/lyndon/freebsd/usr.sbin/adduser/.  It's
functional, but still needs edge case testing and some code cleanup.

--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!)

[Lyndon Nerenberg]

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

Re: What is user uucp good for?

[Lyndon Nerenberg]

 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: Do we still need portmap(8)?

[Lyndon Nerenberg]

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)?

[Lyndon Nerenberg]

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: Do we still need portmap(8)?

[Lyndon Nerenberg]

 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 mumble
! -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: __FreeBSD_version bump for loss of perl

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

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: The future of perl on FreeBSD

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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: Adding a 'bpf' group for /dev/bpf*

[Lyndon Nerenberg]

 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: Mergemaster niggle

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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: uucp user shell and home directory

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

  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

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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: uucp user shell and home directory

[Lyndon Nerenberg]

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

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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

[Lyndon Nerenberg]

 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: ipfw: several equal rules under same number bug

[Lyndon Nerenberg]

 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: make(1) patches to bypass quietness prescribed by @-prefixed commands in Makefiles

[Lyndon Nerenberg]

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?

[Lyndon Nerenberg]

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?

[Lyndon Nerenberg]

 "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

[Lyndon Nerenberg]

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

Process cleanup (was Shared memory ...)

[Lyndon Nerenberg]

 "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

Re: openssl in -current

[Lyndon Nerenberg]

 "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

Re: Crypto progress! (And a Biiiig TODO list)

[Lyndon Nerenberg]

 "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)

[Lyndon Nerenberg]

 "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)

[Lyndon Nerenberg]

 "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: Init (was MAKEDEV et al)

[Lyndon Nerenberg]

 "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: Speaking of moving files (Re: make world broken building fortunes )

[Lyndon Nerenberg]

 "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: HEADSUP: wd driver will be retired!

[Lyndon Nerenberg]

 "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: HEADSUP: wd driver will be retired!

[Lyndon Nerenberg]

 "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!

[Lyndon Nerenberg]

 "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