Re: nis security
On Mon, Sep 08, 2003 at 11:59:04PM +0200, Antoine Jacoutot wrote: I'm building a new network for my company. Right on! I need centralized authentication and looked after LDAP to achieve this. It's a good thing you're designing this /now/ rather than trying to graft it on later. It's not as simple as it seems. Unfortunately, there are 2 points that make me wonder the good use of it: 1. nss_ldap and pam-ldap need FreeBSD-5.1 and are not for production use 2. I really don't feel confident with LDAP For many networks LDAP can be overkill. So, I was thinking about using NIS instead, with which I feel much more confident. I understand it is really not secure, so I was looking about more information on this: why is is unsecure, does it send password in clear text? No, but it sends them in an easily broken format. It's exactly the same situation as a DES /etc/passwd file in the days before master.passwd/shadow passwd files. This can be fixed by combining NIS with Kerberos. Another large problem is that clients used to broadcast for NIS servers and trust the first server to answer. this can be fixed by telling the clients to contact only specific servers for NIS information. ? Does anyone know a solution for securing NIS, using ssh or encrypted tunnels or anything... I am open to any new idea :) IPsec can fix the network sniffing problem, though Kerberos can do that as well and comes with many other advantages. I'm a bit biased, however: I use NIS with Kerberos and think it's the cats pajamas :-) -T -- To give your sheep or cow a large spacious meadow is the way to control him. Shunryu Suzuki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nis security
On Mon, Sep 08, 2003 at 07:02:06PM -0500, Bruce Pea wrote: Does anyone know a solution for securing NIS, using ssh or encrypted tunnels or anything... I am open to any new idea :) IPsec can fix the network sniffing problem, though Kerberos can do that as well and comes with many other advantages. I'm a bit biased, however: I use NIS with Kerberos and think it's the cats pajamas :-) Hey Tilman, s/l/ll/ :-) This sounds exactly like what we are looking for. Can you point us to any docs explaining how you do this?? The rough instructions are fairly simple: * Set up Kerberos and ensure you have a working realm * Set up NIS, but set all the passwd fields to something that doesn't map to a real password (I like 'krb5', others like '*') That's about it. It works because authentication in a Kerberized world doesn't check the password field in the NIS maps anyway (or the /etc/master.passwd file for that matter). Your non-Kerberos app's will break for users that aren't local, but I consider the incentive to replace them a benefit :-) You can get fancy and make a nice little Makefile to do all kinds of maintenance tasks for you (I'm just about finished tying in Mailman into the central auth for the rospa.ca domain). You can try some of the neater features of NIS (netgroups, etc) or fiddle with the config of Kerberos (I like longer ticket lifetimes), but the basic get it working stuff isn't complicated. -T -- When a person is confused, he sees east as west. When he is enlightened, west itself is east. Ta-Hui ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nis security
On Mon, Sep 08, 2003 at 10:28:17PM -0500, Dan Nelson wrote: In the last episode (Sep 08), Tillman Hodgson said: I'm a bit biased, however: I use NIS with Kerberos and think it's the cats pajamas :-) This sounds exactly like what we are looking for. Can you point us to any docs explaining how you do this?? The rough instructions are fairly simple: * Set up Kerberos and ensure you have a working realm * Set up NIS, but set all the passwd fields to something that doesn't map to a real password (I like 'krb5', others like '*') You can do something similar with LDAP, by using pam_ldap for authentication and NIS for the rest of the user info lookup. That seems like a backwards use of LDAP to me - If I was going to use LDAP, I'd rather use Kerberos for authentication and LDAP to provide the user info lookup :-) (This is essentially what active directory is, and combined with Kerberos cross-realm authentication can make for some pretty neat single sign on solutions) -T -- Love is the highest achievement to which any human may aspire. It is an emotion that encompasses the full depth of heart, mind, and soul. - Zensunni Wisdom from the Wandering ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to confirm the options for an NFS mount?
Howdy, How does one confirm that the options listed in /etc/fstab for an NFS mount are actually in place? For example, here's the abbreviated outpout of `mount`: athena:/usr/obj on /usr/obj (nfs, read-only) athena:/usr/src on /usr/src (nfs, read-only) athena:/usr/ports on /usr/ports (nfs) That tells me whether or not the 'ro' flag is used, but doesn't tell me whether any of the other flags (such as 'soft', '-w' and '-r') actualyl in effect. -T -- Often people attempt to live their lives backwards; they try to /have/ more things, or more money, in order to /do/ more of what they want, so they will /be/ happier. The way it actually works is the reverse. You must first /be/ who you really are, then, /do/ what you need to do, in order to /have/ what you want. Margaret Young ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hard disk performance issue
On Sun, Aug 24, 2003 at 10:18:05PM -0500, Chris Newman wrote: Hmm... when I do what you suggest, here's what I get... tigger# dd if=/dev/ad8s1d of=/dev/null bs=64k count=100 100+0 records in 100+0 records out 6553600 bytes transferred in 0.147501 secs (44430888 bytes/sec) tigger# dd if=/dev/ad8s1d of=/dev/null bs=100k count=100 100+0 records in 100+0 records out 1024 bytes transferred in 0.230168 secs (44489246 bytes/sec) tigger# dd if=/dev/ad8s1d of=/dev/null bs=200k count=100 100+0 records in 100+0 records out 2048 bytes transferred in 0.429506 secs (47682693 bytes/sec) ~47MB ? huge difference I'm still not sure at this point what the best way is to evaluate whether I'm getting my money's worth out of this disk/controller. How do I do a good benchmark of the speed? /usr/ports/benchmarks/bonnie++ with and without the new controller? Of course, that'll only tell you if it's faster. Value means that you're paying for extra speed that you actually /need/. The best way to measure this is to benchmark whatever you use this particular computer for and decide if any speed difference is worth the price of the controller. -T -- The supreme irony of life is that hardly anyone gets out alive. - Robert Heinlein ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Copying an entire tree
On Thu, Aug 21, 2003 at 02:23:54PM -0700, Pat Lashley wrote: On Thursday, August 21, 2003 22:19:28 +0200 Nico Meijer [EMAIL PROTECTED] wrote: Is there any simple clean way to copy an entire directory tree and preserve both the flags (like schg) AND hard links within the tree? (And, of course, preserve device special nodes, etc.) Have you looked at rsync? No, I hadn't thought of using rsync for a purely local copy. But now that I've tried it, add it to the list of utilities that lose the flags. (I'm particularly interested in preserving the schg and nodump flags.) So far, the only thing I know of that seems to do everything right is cvsup. But it's really a bit cumbersome to set up for a one-time copy. cpdup, perhaps? (/usr/ports/sysutils/cpdup) -T -- The ultimate question: Why does life exist? The answer: For life's sake. - ANONYMOUS, thought to be of Zensunni origin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
38400 serial boot console through all stages of boot? (repostingfrom sparc64 list)
Howdy, I originally posted this to the sparc64 mailing list and haven't received a response. It occurs to me that this might not be sparc specific and so I'm reposting it on [EMAIL PROTECTED] It's a -CURRENT sparc64 system, so I'm not sure that -questions@ covers all the territory either :-) I have the serial boot console and a login getty working, and I wanted to move them to 38400 from the default 9600. The short story is that it works until it mounts root, then I get garbage like this: xx|[EMAIL PROTECTED]|@[EMAIL PROTECTED]@@|[EMAIL PROTECTED]||x|[EMAIL PROTECTED]|[EMAIL PROTECTED]@|x|x||x|@x|x|xx|[EMAIL PROTECTED]|@|x|x| (etc) Which I assume is due a serial speed mismatch. After a little bit of time, the computer finishes booting and I'm presented with a working serial login (i.e., the speed matches again). Here's a rough synopsis of what happens: ... Timecounters tick every 0.976 msec IPsec: Initialized Security Association Processing. IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled ad0: 8223MB ST38410A [16708/16/63] at ata2-master WDMA2 acd0: CDROM CRD-8322B at ata3-master PIO4 Mounting root from ufs:/dev/ad0a |[EMAIL PROTECTED]|x|[EMAIL PROTECTED]@x|@xx|[EMAIL PROTECTED]|@@|@xx@|xpx@@xx|xx@ (etc for several lines) FreeBSD/sparc64 (caliban.rospa.ca) (ttyb) login: The parts that work at 38400: * Getting into the Sparc firmware via ~# in tip (this is /so/ handy!) * Getting into the loader (this is /so/ handy!) * The kernel messages reporting detected hardware * The getty to login To set this up, I've: * Set ttyb setenv'd as the input and output devices and the speed set to 38400 in the Sparc firmware (this part is sparc64 specific) * Set BOOT_COMCONSOLE_SPEED= 38400 in /etc/make.conf * Set options CONSPEED=38400 in my kernel config file * cd /usr/src time make buildkernel make installkernel * cd /usr/src/sys/boot make all install clean * sunlabel -B ad0 (sparc64 specific - sunlabel rather than bsdlabel) Am I missing something? -T -- Page 2: Unix today is nothing less than a worldwide culture, comprising many tools, ideas and customs. - Harley Hahn, _The Unix Companion_ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Make buildworld failure
On Tue, Aug 19, 2003 at 09:03:11PM -0400, Jud wrote: On Tue, 19 Aug 2003 15:49:38 -0500, Charles Howse [EMAIL PROTECTED] wrote: Very interesting. On page 490 of FreeBSD Unleashed it references the -j4 parameter as a way to speed up the make buildworld process by spawning multiple simultaneous processes. The same thing is referenced in Chapter 20 of the FreeBSD Handbook. Is this now depreciated? Whether deprecated or not, many posts to this mailing list have said -j4 doesn't speed up make buildworld anyway, and that's been my experience. I'm sure it depends on your setup. To use -j effectively, try putting /usr/obj and /usr/src on different drives (ideally, on drives dedicated to the task, meaning a third drive for the OS itself) and testing with `time make buildkernel -jX` (where X is greater than 1). You should see a measurable decrease in compile time even on a single CPU system simply because you can keep both disks busier. On the other hand, if you have only a single CPU and a single disk and one or the other is maxed out it's unlikely that using -j will help (as you've seen). Chapter 18 of _Absolute BSD_ (Michael Lucas) has a description of tuning buildkernel. If you compare the output of `top` with `vmstat 5` while building without -j on a box with a reasonably fast CPU and a single disk you'll probably see that the CPU is idle for some percentage of the time, but the number of items under the 'b' column in vmstat is occassionally above 0. This means that the CPU has cycles available yet tasks are blocking on disk: classic disk IO bottlenecking. 'Course, as I say all this, building with -j on sparc64 is broken in -CURRENT at the moment so I'm not using -j for a while. Heh. It's handy when it works :-) -T -- Surely the 4 sysadmins of the apocalypse should be: edquota, rm -rf, kill -9, and shutdown. - Rob Blake ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
