MIT kerberos and ssh
I didn't get any replies on freebsd-questions for this one maybe someone here could help? --- I have been trying to get a working MIT Kerberos KDC on a server running 6.1-Release. I have been able to keep the heimdal version from being built during several past 'make worlds' and I have compiled and installed MIT krb5 from /usr/ports (current per portmanager). I have been getting an error tryiing to start sshd (also built from /usr/ports), it complains about not finding 'libkrb5.so.8' then exits. I have been able to start the KDC but have not gotten much further as I would like to fix the ssh problem first. My questions are as follows: 1. Is libkrb5.so.8 a heimdal library? 2. Which source directories are the correct ones to use, /usr/src/kerberos - /usr/src/secure, or /usr/ports/security/krb5 - /usr/ports/security/openssh? 3. Why are there two different directories i.e; /usr/src and /usr/ports for the same source? 4. How do I get 'kerberized' ssh and give configure directives to the krb5 make to include GSSAPI support? 5. Is there a certain build order for MIT kerberos and openssh? I have read both the Handbook and the 'Complete' book on this subject and have not been able to glean enough information to get me going, Google didn't help much either. I have 6 Debian clients, 2 WinXP clients, and 1 Debian KDC slave and wanted this machine to be an MIT-KDC master and yet avoid the apparent 'kadmin' server incompatibility between Heimdal and MIT Kerberos (which all the Debian clients run). I am also very comfortable with the MIT version. Any words of wisdom would be greatly appreciated. Michael ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
TLS - implementing linux one in fbsd
Hi I am student working on SoC project - extending linuxolator, now I am working on implementing linux TLS in FreeBSD. Here is what I think/know and I like you to comment on this, thnx. Roman - Linux and FreeBSD TLS implementation - comparison Both systems use per-thread setting of where is the tls area stored. This setting is loaded into active threads GDT and can be accessed via %gs register. This GDT setup is done on every context switch. Linux uses strict 1:1 threading so every thread is in fact process, so thread creation is done using plain clone()/fork(). FreeBSD uses M:N (including 1:1) threading. Threads are created via pthread_create() call to threading library. In kernel there's thr_new() syscall or thread_create() syscall. I didnt find the connection between threading library and kernel but I assume its using one of the syscalls For setting up the GDT for the thread Linux uses syscall set_thread_area() (TODO - how exactly? its unclear what it does). I dont know how FreeBSD does it but I think it might be done via params to the syscalls (TODO - how is it done?) Remaining questions: clone() - 2.6.x glibc fork() implementation uses clone() syscall. is it supposed to create a thread or just a process? I think its process but why is the binary (ls, date and probably some other) linked to pthread library? is it just Linux strangeness? I dont see a reason for ls to be threaded... does anyone see? set/get tid - does it relate to TLS at all? I dont think so but you never know. The tid thing is unclear to me. The clone() syscall is passed CLONE_CHILD_SETTID CLONE_CHILD_CLEARTID which should be mutually exclusive. I dont believe much its a mistake.. but the code is clear: p-set_child_tid = (clone_flags CLONE_CHILD_SETTID) ? child_tidptr : NULL; p-clear_child_tid = (clone_flags CLONE_CHILD_CLEARTID) ? child_tidptr: NULL; kostik belousov pointed out that this is used for futexes, so not interesting for this Possible mapping from Linux to FreeBSD: To me it seems that the the set_thread_area() syscall is used in the process of thread creation to set where the tls is stored. In FreeBSD we use cpu_set_user_tls() for this. So it might be enough to just wrap call to cpu_set_user_tls() into the syscall. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFC][patch] dhclient Classless Static Routes support
On Mon, Jun 19, 2006 at 09:26:12PM -0700, Brooks Davis wrote: On Sun, Jun 18, 2006 at 01:12:22PM +0400, Andrey V. Elsukov wrote: Hi! I have implemented RFC3442 support for the FreeBSD dhclient. Patch can be fetched from http://butcher.heavennet.ru/patches/other/dhclient/ I have a small bit of testing with isc-dhcpd and dnsmasqd. And i think it works fine. I have tested with: 1) Normal classless routes: 10.0.0.0/21 router, 10.1.0.0/19 router 2) default route 3) link routes: 192.168.0.0/24 0.0.0.0, 192.168.1.0/24 0.0.0.0 I don't know what i should make with incorrect data received from DHCP server.. At a glance I don't see any major issues. I won't have time to do anything more with it for at least a couple weeks. I'd suggest filing a PR with it to ensure it isn't lost. Ed, if you're interested in it, feel free to commit. Hi Brooks. I'll be testing this out shortly and plan to commit it soon. One question I had for you was how we want to handle dhclient with respect to OpenBSD -- I seem to recall that we've decided to own our dhclient after the import. So it would be advantageous if OpenBSD decides to take the patch, but not necessary. -ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIT kerberos and ssh
On Mon, Jun 19, 2006 at 09:59:06PM -0500, Michael D. Norwick wrote: I didn't get any replies on freebsd-questions for this one maybe someone here could help? (Your line-wrap appears to be broken, I've reformatted it below) I recommend checkign with the kerberos at mit dot edu list, this topic comes up often there. --- I have been trying to get a working MIT Kerberos KDC on a server running 6.1-Release. I have been able to keep the heimdal version from being built during several past 'make worlds' and I have compiled and installed MIT krb5 from /usr/ports (current per portmanager). I leave the standard Heimdal stuff in place. In /etc/make.conf, I define KRB5_HOME=/usr/local/krb5, and MIT Kerberos installs into that location. I then use $PATH. This results in me being able to use Heimdal and MIT clients more or less interchangeably. I have been getting an error tryiing to start sshd (also built from /usr/ports), it complains about not finding 'libkrb5.so.8' then exits. I have been able to start the KDC but have not gotten much further as I would like to fix the ssh problem first. Do the standard Kerberos clients work? Can you kinit and telnet -x? Does remote kadmin work? 3. Why are there two different directories i.e; /usr/src and /usr/ports for the same source? The Heimdal included in base isn't complete, and may lag a dot release or behind the official version. 4. How do I get 'kerberized' ssh and give configure directives to the krb5 make to include GSSAPI support? I don't use ssh with Kerberos (telent -x and rcp -x work for me) so unfortunately I can't help you much with this. I know that OpenSSH 3.7.x and 3.8+ use incompatible methods and won't work together, so keep the OpenSSH version the same on both ends. Another item I seem to vaguely recall is that the older Kerberos config items (instead of the newer GSSAPI config items) only work with 'ssh -1'. I have read both the Handbook and the 'Complete' book on this subject and have not been able to glean enough information to get me going, Google didn't help much either. I have 6 Debian clients, 2 WinXP clients, and 1 Debian KDC slave and wanted this machine to be an MIT-KDC master and yet avoid the apparent 'kadmin' server incompatibility between Heimdal and MIT Kerberos (which all the Debian clients run). I am also very comfortable with the MIT version. Any words of wisdom would be greatly appreciated. A long time ago I started working on an update to the Kerberos5 chapter, which unfortunately I never completed and the official chapter in the Handbook may have moved on (creating a doc fork of sorts, I suppose). Anyway, my mostly-finished-but-not-polished revised version is at http://www.seekingfire.com/freebsd-doc/kerberos5.html if you want to take a peek at it to see if it's helpful. (My apologies to Giorgos Keramidas, I totally dropped the ball on this) The type of KDC won't matter -- I do cross-realm authentication between MIT and Heimdal and all my Kerberos client apps handle it fine. The only incompatibility is in the kadmin tool to manage the KDC. Since I perform management at the secured console it's never really affected me. I keep some Kerberos info online a http://www.seekingfire.com/projects/kerberos/ that you might fine useful. I haven't added to it in a while, but Kerberos isn't exactly a fast-moving target anyway ;-) The link http://shankerbalan.net/tech/freebsd_kerberos.txt in particular includes what looks like useful SSH info. -T -- Statistics are the triumph of the quantitative method, and the quantitative method is the victory of sterility and death. -- Hillaire Belloc, _The Silence of the Sea_ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIT kerberos and ssh
On 2006-06-20 10:21, Tillman Hodgson [EMAIL PROTECTED] wrote: A long time ago I started working on an update to the Kerberos5 chapter, which unfortunately I never completed and the official chapter in the Handbook may have moved on (creating a doc fork of sorts, I suppose). Anyway, my mostly-finished-but-not-polished revised version is at http://www.seekingfire.com/freebsd-doc/kerberos5.html if you want to take a peek at it to see if it's helpful. (My apologies to Giorgos Keramidas, I totally dropped the ball on this) Hi Tillman lists, That's fine. If you are still interested in merging these changes to the Handbook, we can still do it :) - Giorgos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Tester needed, picture heavy webserver preferred.
(For picture heavy substitute the word you all have in your spamfilters.) I'm writing a serverside web-cache and I am looking for a web-operator in the heavy duty picture category to get some input and possibly a beta tester. I would prefer a site which runs FreeBSD, and I it to be somebody who is into serious bandwidth AND clue. Should any of you know of a good candidate, please tell them to email me. Thanks in advance! Poul-Henning PS: Full discretion! The software will be delivered in plain brown IP packets with no source address :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MIT kerberos and ssh
On Tue, Jun 20, 2006 at 07:51:37PM +0300, Giorgos Keramidas wrote: On 2006-06-20 10:21, Tillman Hodgson [EMAIL PROTECTED] wrote: A long time ago I started working on an update to the Kerberos5 chapter, which unfortunately I never completed and the official chapter in the Handbook may have moved on (creating a doc fork of sorts, I suppose). Anyway, my mostly-finished-but-not-polished revised version is at http://www.seekingfire.com/freebsd-doc/kerberos5.html if you want to take a peek at it to see if it's helpful. (My apologies to Giorgos Keramidas, I totally dropped the ball on this) Hi Tillman lists, That's fine. If you are still interested in merging these changes to the Handbook, we can still do it :) I'm interested in doing that, yes. I'll move this off-list. -T -- Page 461: Tools that are simple enough to use the first day are often a real pain after the first month. - Harley Hahn, _The Unix Companion_ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TLS - implementing linux one in fbsd
On Tuesday 20 June 2006 20:09, Divacky Roman wrote: Hi I am student working on SoC project - extending linuxolator, now I am working on implementing linux TLS in FreeBSD. Here is what I think/know and I like you to comment on this, thnx. Roman - Linux and FreeBSD TLS implementation - comparison Both systems use per-thread setting of where is the tls area stored. This setting is loaded into active threads GDT and can be accessed via %gs register. This GDT setup is done on every context switch. Yes. Linux uses strict 1:1 threading so every thread is in fact process, so thread creation is done using plain clone()/fork(). FreeBSD uses M:N (including 1:1) threading. Threads are created via pthread_create() call to threading library. In kernel there's thr_new() syscall or thread_create() syscall. I didnt find the connection between threading library and kernel but I assume its using one of the syscalls The M:N and 1:1 threading in FreeBSD use different mechanisms to implement TLS, M:N implements it in userland, while 1:1 implements it in kernel. the thr_new or thr_create are used for 1:1 threading, right now libthr uses thr_new to atomically setup a thread, this includes, storing TID, setting TLS, and maybe signal mask( not implemented ) , cpu affinity mask etcs(not implemented), scheduling scope, in one word, it is intended to map most part of pthread_attr into kernel world. For setting up the GDT for the thread Linux uses syscall set_thread_area() (TODO - how exactly? its unclear what it does). I dont know how FreeBSD does it but I think it might be done via params to the syscalls (TODO - how is it done?) If you use thr_new, it is not necessary to use set_thread_area, I am not sure you need to change TLS pointer again after the thread is created, I think only main thread may need this feature, in FreeBSD, setting thread's TLS pointer is via libc function: _set_tp(void *tp). Remaining questions: clone() - 2.6.x glibc fork() implementation uses clone() syscall. is it supposed to create a thread or just a process? I think its process but why is the binary (ls, date and probably some other) linked to pthread library? is it just Linux strangeness? I dont see a reason for ls to be threaded... does anyone see? Dunno. set/get tid - does it relate to TLS at all? I dont think so but you never know. The tid thing is unclear to me. The clone() syscall is passed CLONE_CHILD_SETTID CLONE_CHILD_CLEARTID which should be mutually exclusive. I dont believe much its a mistake.. but the code is clear: p-set_child_tid = (clone_flags CLONE_CHILD_SETTID) ? child_tidptr : NULL; p-clear_child_tid = (clone_flags CLONE_CHILD_CLEARTID) ? child_tidptr: NULL; kostik belousov pointed out that this is used for futexes, so not interesting for this I think it is used for futex, and the childtid is use to implement pthread_join and garbage collection in thread library, the parent tid pointer (if I recall correctly) is used by parent thread to retrieve child tid. Possible mapping from Linux to FreeBSD: To me it seems that the the set_thread_area() syscall is used in the process of thread creation to set where the tls is stored. In FreeBSD we use cpu_set_user_tls() for this. So it might be enough to just wrap call to cpu_set_user_tls() into the syscall. cpu_set_user_tls is used by thr_new syscall internally to setup TLS pointer before executing user code, the thr_new syscall's only user is libthr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem: fpa(4) on sparc64 6.1-RELEASE
I am getting a panic with a GENERIC with all non-available hardware drivers stripped out with device fddi and device fpa in the config. The only things I added to GENERIC after stripping out the unneeded things was the fddi, the sound, and the openfirmware. The system boots fine with the fddi stuff commented out of the config. Any suggestions? Is anyone working on this? Console log follows: screen not found. Can't open input device. Keyboard not present. Using ttya for input and output. SPARCengine(tm)Ultra(tm) AXi (UltraSPARC-IIi 300MHz), No Keyboard OpenBoot 3.10.4 SME, 256 MB memory installed, Serial #10425242. Ethernet address 8:0:20:9f:13:9a, Host ID: 809f139a. Initializing Memory ok boot Boot device: disk:a File and args: FreeBSD/sparc64 boot block Boot path: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot loader: /boot/loader Consoles: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Sun May 7 07:03:17 UTC 2006) bootpath=/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x36b508+0x52e58 syms=[0x8+0x59a60+0x8+0x4af83] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc0058000. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Tue Jun 20 02:01:14 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/REN Timecounter tick frequency 38484 Hz quality 1000 real memory = 268435456 (256 MB) avail memory = 241123328 (229 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (300.01 MHz CPU) nexus0: Open Firmware Nexus device pcib0: U2P UPA-PCI bridge on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A pcib0: [FAST] pcib0: [FAST] pcib0: [GIANT-LOCKED] pcib0: [GIANT-LOCKED] pcib0 dvma: DVMA map: 0xc000 to 0xc3ff pci0: OFW PCI bus on pcib0 pcib1: APB PCI-PCI bridge at device 1.1 on pci0 pci1: OFW PCI bus on pcib1 ebus0: PCI-EBus2 bridge mem 0xf000-0xf0ff,0xf100-0xf17f at device 1.0 on pci1 auxio0: Sun Auxiliary I/O addr 0x1400726000-0x1400726003,0x1400728000-0x1400728003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f003 on ebus0 ebus0: power addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: SUNW,pll addr 0x1400504000-0x1400504002 (no driver attached) puc0: Siemens SAB 82532 dual channel SCC addr 0x140040-0x140040007f irq 43 on ebus0 uart0: SAB 82532 v3.2, channel A on puc0 uart0: CTS oflow uart0: console (38400,n,8,1) uart1: SAB 82532 v3.2, channel B on puc0 uart1: CTS oflow uart2: 16550 or compatible addr 0x14003803f8-0x14003803ff irq 41 on ebus0 uart2: keyboard (1200,n,8,1) uart2: keyboard not present uart3: 16550 or compatible addr 0x14003602f8-0x14003602ff irq 42 on ebus0 ebus0: ecpp addr 0x1400340278-0x1400340287,0x140030015c-0x140030015d,0x140070-0x14007f irq 34 (no driver attached) ebus0: fdthree addr 0x14003203f0-0x14003203f7,0x1400706000-0x140070600f,0x140072-0x1400720003 irq 39 (no driver attached) eeprom0: EEPROM/clock addr 0x14-0x141fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 809f139a ebus0: flashprom addr 0x10-0x1f (no driver attached) ebus0: beeper addr 0x1400722000-0x1400722003 (no driver attached) ebus0: SUNW,rasctrl addr 0x140060-0x140063 irq 40,37 (no driver attached) hme0: Sun HME 10/100 Ethernet mem 0x40008000-0x4000 at device 1.1 on pci1 miibus0: MII bus on hme0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: Ethernet address: 08:00:20:9f:13:9a pcm0: AudioPCI ES1373-B port 0x800400-0x80043f at device 4.0 on pci1 pcm0: TriTech TR28023 AC97 Codec pcm0: Playback: DAC2 / Record: ADC pcib2: APB PCI-PCI bridge at device 1.0 on pci0 pci2: OFW PCI bus on pcib2 sym0: 875 port 0x400-0x4ff mem 0x1000-0x10ff,0x2000-0x2fff at device 1.0 on pci2 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym0: [GIANT-LOCKED] sym1: 875 port 0x800-0x8ff mem 0x3000-0x30ff,0x4000-0x4fff at device 1.1 on pci2 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: [GIANT-LOCKED] fpa0: Digital DEFPA PCI FDDI Controller port 0xc00-0xc7f mem 0x5000-0x507f,0x1-0x1 at device 2.0 on pci2 panic: trap: fast data access mmu miss Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Resetting ... ___ freebsd-hackers@freebsd.org mailing list
curious 6.1 GRE behaviour.
I was using some GRE tunnels on 6.1-RELEASE recently. The odd thing I'm finding is that the initial creation of the tunnel using cloned_interfaces and ifconfig_gre0=blah results in the gre0 interface being created without the running bit set. tcpdump on the interface or even ifconfig gre0 up starts it. This is also odd because the UP flag is set. Ie: [1:2:[EMAIL PROTECTED]:~ ifconfig [...] gre0: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1476 tunnel inet x.x.x.x -- y.y.y.y inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 inet a.a.a.a -- b.b.b.b netmask 0xfffe [1:2:[EMAIL PROTECTED]:~ ifconfig gre0 up [1:3:[EMAIL PROTECTED]:~ ifconfig [...] gre0: flags=9051UP,POINTOPOINT,RUNNING,LINK0,MULTICAST mtu 1476 tunnel inet x.x.x.x -- y.y.y.y inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 inet a.a.a.a -- b.b.b.b netmask 0xfffe Dave. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
