GSSAPI Key Exchange in sshd?
I'm curious if there are technical (or other) reasons that prevent FreeBSD from adding RFC 4462 (GSSAPI Key Exchange) support to sshd. The MIT Kerberos team first requested this four years ago, and implementation patches have been available for years at: http:// www.sxw.org.uk/computing/patches/openssh.html The author of those patches has offered (without much public response) to allow integration of the patches into the openssh source distribution, so I don't think licensing would be an issue. This would be incredibly useful to me, as it'd remove the burden of site-wide ssh host key distribution. Regards, Kevin Way ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Should URL's be pervasive.
If you're really lazy and want to be able to do: telnet smtp://localhost I suggest you look into this relatively new invention called '/etc/services' and read some manual pages. You'll find you can do something quite similar, and much saner. I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea lazy. I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote: Kevin Way [EMAIL PROTECTED] types: I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea lazy. I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I would concur with that, so long as you remember that local file access involves someone making usually-privileged system calls to arrange to map those remote name spaces into the local name space. That is different from making URLs pervasive. Agreed. You'll notice I agreed with Michael Sinz's post, not the pro-URL posts. I like the idea of being able to say... mount -t http http://www.freebsd.org/ /www/freebsd cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html even a simple example like 'cat http://www.freebsd.org/' seems nice, but it raises as more questions than it answers. Obviously protocols which are not file oriented won't translate effectively into filesystems. mailto is an excellent example of a scheme that doesn't translate effectively into a filesystem translation layer. I'd have no idea what to do with a mailto url, or how to reference it as a filesystem. Combine the above filesystem concept with something like amd, and many activities become extremely convenient. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. Those are all file systems, and operations on the things on them all have pretty much the same semantics. This isn't true for URLs in general. Agreed. It's true for some subset of the available schemes, and don't think anyone would object to file system modules for ftp or http. this is what the post I agred with was suggesting. this is what i believe would be a good idea. You can even do this in userland with an nfs server API if you want it to be portable. Novel idea. I'll file it into the maybe pile. I don't know of any application that handles local files that responds to any open error by prompting for a password. If open can now return an HTTP 401 error, every application is going to need to be able to deal with that in some sane way. Either that, or users are going to have to know the proper syntax for usernames and passwords in every URL scheme they deal with - and start putting passwords on command lines, and other things that give security officers nightmares. I would imagine that an http filesystem layer would return EACCES for a 401, as that would probably cause any program to return a sane error to the user. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Conceptually, it may be very simple. In practice, it's very, very messy. The correct thing to do with a URL is going to depend on the application that's doing it, what the application is doing, and the scheme for the URL. The application is really the only thing that can figure all that out. In the simplest possible example, cat can just treat appropriate URLs like files and read from them. vi - or something that vi is talking to - needs to be taught how to deal with streaming data in some way. Yes, unfortunately all ideas are just a Simple Matter of Programming... One miscommunication I should apologize for, I'm not suggesting the URLification of FreeBSD. I'm suggesting that it would be a Good Thing if files available via any common networked file transfer protocol were able to be accessed via standard system calls. In summary, each command needs to decide - possibly on a case-by-case basis whether or not the string it's got is a URL or a file name. It needs to decide how the operation it's been asked to be performed can be performed on the object that URL represents, and if so how it should be mapped. If it's a URL, the application may well have to deal with events that don't happen with local files. I really don't want all that in every command. I want it in a filesystem layer, where appropriate, as described above. Anyway, in conclusion it would seem to me that we agree, but there was a misunderstanding because I did a poor job of clipping relevant text to show what it was I was agreeing with. I apologize for the miscommunication. Kevin Way PGP signature
:q:q![kevin.way@overtone.org: Re: import NetBSD rc system]
- Forwarded message from Kevin Way [EMAIL PROTECTED] - Date: Tue, 14 Aug 2001 06:34:26 + From: Kevin Way [EMAIL PROTECTED] To: Gordon Tetlow [EMAIL PROTECTED] Subject: Re: import NetBSD rc system On Mon, Aug 13, 2001 at 11:10:43PM -0700, Gordon Tetlow wrote: Here's my big question. Do we try to maintain our boot order? Or are we going to go with the boot order as presented by the NetBSD stuff? I don't see any reason to force the boot order to be maintained. As long as the dependancies are set correctly, i'd think the boot order would be determined solely by the output of rcorder. What am I missing? -Kevin Way - End forwarded message - -- If it weren't for my horse, I wouldn't have spent that year in college. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
Is there anything we need to talk about still, or do we just need an unemployed guy who understands the problem to bang out a big pile of code. If we need to hold joint discussions, what are the outstanding issues? Given the lack of any response, I didn't do any further work. My previous work on the NetBSD import is available at http://overtone.org/rc.d/ The version contained in the tarball there requires that you flip rc_new to YES in your rc.conf, else it uses the old stuff. It's not compatible with BOOTP diskless booting out of the box, though it includes the trivial patch to make that work. It includes some minor notes I made for myself while I first worked on the project. There's also a TODO list, noting the items which still need work done (beyond debugging) Everything in the tarball is derived from BSD licensed sources, and it all remains under the BSD license. If anybody decides that they want to fix this up and use it, I'd be more than happy to answer any questions, or accept any flames that you might have. -Kevin Way PGP signature
Re: import NetBSD rc system
On Mon, Aug 13, 2001 at 11:10:43PM -0700, Gordon Tetlow wrote: Here's my big question. Do we try to maintain our boot order? Or are we going to go with the boot order as presented by the NetBSD stuff? I don't see any reason to force the boot order to be maintained. As long as the dependancies are set correctly, i'd think the boot order would be determined solely by the output of rcorder. What am I missing? -Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
Well, it's now been about 2 months since the initial NetBSD import discussion occured on this list, and as far as I can tell, here's where we stand. - David O'Brien did a vendor import of the unported NetBSD rc system - there was a group consensus that we needed to come up with some intelligent talking points before we approached the NetBSD maintainer about how to do this, how coordinated we want the two rc systems to be, and what not. I'm back in town for a few weeks and I'd like to get this project done, especially having noted that it's really a sweet system. Is there anything we need to talk about still, or do we just need an unemployed guy who understands the problem to bang out a big pile of code. If we need to hold joint discussions, what are the outstanding issues? If not, then I'm your unemployed guy with time to kill. -Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
FWIW: sendmail does not _require_ DNS, but it operates better in the presence of DNS, even though it can provide degraded service without it. The same goes for sendmail's need for syslogd. Thus there are both hard and soft requirements. Lack of soft requirements means degraded, but functional service (e.g. lack of NIS does not mean you should not start getty on the console to permit root logins). Eivend noted this in his handy requirements list, as well. It would be a divergence from the original NetBSD code, but this could be implemented by adding 'WANTS' in addition to 'REQUIRES', and calling warn if a want isn't fulfilled. An excellent point. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re: import NetBSD rc system [summary]
[EMAIL PROTECTED] wrote: At 10:01 PM -0400 6/12/01, Kevin Way wrote: David Xu wrote: Is there any plan to import NetBSD rc system, I am willing to see it appears in FreeBSD 5.0. Here's the status of this project at the moment as I see. Please let me know if I've misunderstood anything, or if anybody has had a change of heart. I see no reference to the thread Plan to import NetBSD rc system from Sheldon Hearn, where he said: Thanks Garance, that's exactly why I posted the summary. My current status is: -setup dedicated net freebsd -CURRENT boxes -made sure rcorder worked on fbsd -ported rc, rc.subr, and started with the individual rc.d scripts Seeing as there are a few of us who are working on independant implementations of this port, perhaps we should follow Sheldon's original advice, and after USENIX, let Sheldon decide what changes each of us made were good/bad, and go from there? I apologize if the formatting of this message is botched, I'm using an awful web-mail client, as the machine i read e-mail on bit the dust this morning. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
in fact, the require keyword isn't sufficient in it's own. there should be pre_require and post_require keywords since nfsd needs to start mountd before to start nfsd then rpc.statd and rpc.lockd have to be started after nfsd. My answer to this, in the reasoning that NetBSD compatibility is important, so I'd rather not change anything unneccessarily, was to create a meta script... i don't have the code in front of me, but basically it went like this nfs: PROVIDE: nfs REQUIRE: nfsd statd lockd nfsd: PROVIDE nfsd REQUIRED portmap mountd statd: PROVIDE statd REQUIRE nfsd and so on, and so forth. If I understood your concern correctly, then this should take care of things nicely. My apologies for the typos, i'm typing on a freshly broken finger and haven't gotten quite used to it yet. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
Also, NetBSD doesn't seem to formalize chaining to /usr/pkg/etc/rc.d or /usr/local/etc/rc.d, unless I missed that. packages are given startup space in /etc/rc.conf.d/$command, where $command is setby the first argument to load_rc_config. -Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
First, there are some weaknesses in netbsd's system that we don't want to replicate. Are these identified yet? Second, Eivind has already done some excellent work in this area. I'm guessing this code dates to before the new NetBSD startup system. It almost looks like this could've been proof-of-concept code for the NetBSD startup code that I've been staring at for the past few hours. It lacks some of the refinement and flexibility of the NetBSD code though. He does have an excellent requirements doc though, which is definitely a keeper. Third, we want to gather the people who are interested in working on this project on a mailing list... If you're heading up the mailing list, please put me on it. I'm interested in helping with the initial port and future maintainance of this, as may be evidenced by an extreme overabundance of posts by me on this subject. (my apologies to the innocents who don't care at all about this thread) For the moment, I'm continuing with my own local port, with the full knowledge that my code may end up being an intellectual exercise. I'll post code as soon as I can verify that it's at least to the 'works for me' stage. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
On Mon, Jun 11, 2001 at 09:25:28PM -0700, Jordan Hubbard wrote: Guys, guys. The NetBSD /etc/rc system is good. We should stop arguing about it and just focus on figuring out who's going to integrate it or the whole conversation concerns a moot point anyway.:) I'll do it, if nobody has any objections to that. I just ordered a spare machine a few days ago. I'll install -CURRENT on it, and start the integration. I've been needing something to keep myself out of trouble. -Kevin Way -- Obscenity is the crutch of inarticulate motherfuckers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
import NetBSD rc system [summary]
Is there any plan to import NetBSD rc system, I am willing to see it appears in FreeBSD 5.0. Here's the status of this project at the moment as I see. Please let me know if I've misunderstood anything, or if anybody has had a change of heart. Both Gordon Tetlow and myself have volunteered to start the work seperately (which I'm assuming isn't entirely a bad thing). Doug Barton started work on this before, but got sidetracked by unrelated -CURRENT troubles. Any chance you have anything helpful for us, from your previous efforts, Doug? Mike Meyer has volunteered to assist, (and those of you who have CueCat's should check out his nifty little CueCat utility) and last but certainly not least, Jordan Hubbard just wants somebody to stop talking and code. :-) [EMAIL PROTECTED] mentioned the first of the many adjustments to be made, this one regarding mergemaster. I've started a project homepage at http://overtone.org/rc.d/ as I get code together, and released, I'll keep it updated, unless it turns out that Gordon Tetlow is a machine, and integrates the whole thing before I can get NetBSD -current and FreeBSD -current installed. -Kevin Way PGP signature
Re: speeding up /etc/security
Does /etc/security take filesystem mounted with: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. Note: this option is worthless if a public available suid or sgid wrapper like suidperl(1) is installed on your system. into account? If so, and the filesystems have nothing on them that needs suid you could mount 'm this way The answer there is 'sort of'. /etc/security checks all ufs partitions that aren't marked nosuid. if you're using anything other than UFS (e.g. MFS,ext2,whatever), it's not getting checked at all. Kevin Way PGP signature
Re: speeding up /etc/security
The answer there is 'sort of'. /etc/security checks all ufs partitions
that aren't marked nosuid. if you're using anything other than UFS
(e.g. MFS,ext2,whatever), it's not getting checked at all.
i hate to followup to my own message, but in order for the SUID checks to
be accurate, is there a reson we don't do something like the following?
--- security.orig Mon Jun 4 22:26:01 2001
+++ securityMon Jun 4 22:31:47 2001
@@ -69,7 +69,7 @@
# Note that one of the original problems, the possibility of overrunning
# the args to ls, is still here...
#
-MP=`mount -t ufs | grep -v nosuid | awk '{ print $3 }' | sort`
+MP=`( mount -t cd9660; mount -t ext2fs; mount -t ffs; mount -t ifs; mount -t lfs;
+mount -t mfs; mount -t ufs ) | grep -v ' nosuid' | awk '{ print $3 }' | sort` set
+${MP}
while [ $# -ge 1 ]; do
mount=$1
-Kevin Way
PGP signature
vmware borked for me
I don't know if I'm alone in having this problem, but my machine has a nasty habit of hanging solid while using vmware2 (can't drop to kernel debugger, no dump, nothing). If this problem doesn't hit you, then it might work nicely. The restart time is about 30 seconds or so, then you can assume the VM will run at about 50% speed, compared to native, in my experience. Kevin Way On Tue, Apr 24, 2001 at 01:05:46PM -0700, Alfred Perlstein wrote: So I've got this really elite machinery here to test on, problem is that booting takes about 2 minutes each time I make a bad kernel, s... Anyone using anything like vmware in order to have a rapid reboot/test cycle for low level FreeBSD kernel coding? How fast is it to restart the vmware environent and do I stand a chance in hell of getting it working on FreeBSD-current? thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message PGP signature
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
I like these changes. I'm definitely in favor of code that corrects for the DST handling oddities that sysadmins have to deal with. This would be especially valuable for companies which might have deployments in 25 different time zones globally, which for reasons that are out of scope can't be converted to UTC. The argument that the sysadmin should know the results of putting a cronjob at a certain time become much weaker in that scenario. Additionally, the fact of the matter is that most DST crossovers occur during low-usage periods for typical servers. Given a choice of performing resource-intensive daily chores at a time of low usage, or wasting three hours each night, because twice a year there's a clock jump, I'll take the fully utilized server please. The one thing that has me giving some amount of hesitation, though it's trivial, is the fact that this patch is based solely on clock skew. My initial reaction is that I'd like the patch to check if the skew has been caused by a time zone shift, though honestly, I can't think of another scenario where a properly running server's clock would jump. I'll gladly retract my endorsement of this type of change if somebody can note scenarios where this could have negative effects equal to or greater than the negative effects of the current system. -- kevin way [EMAIL PROTECTED] worldgate communications software engineer +1 215 354 5287 PGP signature
Re: Silent FreeBSD
To solve this problem, I invested in one large, fast, fileserver and then ran the noise-critical machines diskless, with PXE boot. To deal with the noise of the fileserver, I bought an enclosed rack. My previous solutions which did an admirable job, were to: a) purchase the overly expensive, quiet power supplies (you can find them easily by going to google and searching for 'quiet power supply' or some such similar thing) b) run fans under standard voltage, with an underclocked CPU c) use a small flash IDE device for boot d) use an old laptop Good luck! -- kevin way [EMAIL PROTECTED] worldgate communications software engineer +1 215 354 5287 PGP signature
