Re: Heimdal Kerberos with LDAP support
Denis Lemire wrote: I would like to setup Heimdal Kerberos and use OpenLDAP to store its database. Too my knowledge the kerberos installation in the base of FreeBSD 5.4 does not support LDAP. I could install from ports but then I end up with two kerberos installations which is sure to give me a headache somewhere down the line. How can I replace the Kerberos installation in the base with the one from ports with LDAP support? there was a related thread the past week. http://lists.freebsd.org/pipermail/freebsd-ports/2005-June/023760.html the problem seems be that there isn't an official position regarding to how to resolve conflicts between programs that are present in the base system and in ports, anyway you can find some workarounds if you read the whole thread. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
debugging system libraries
Hello, I run an application which segsfaults in the libpthread library and I wonder if it could be possible enable debuging info in this libraries. By now I added -g to the list the global compile flags but the symbols are stripped by the installation script. how could I get system libraries with symbols? thank you. (gdb) bt #0 0x282ec31b in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x282e4902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x in ?? () ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
kadmin (heimdal port) ignores the ldap backend
Hello,
I'm testing a new configuration with heimdal and the ldap backend
but kadmin is completely ignoring the ldap directive in the dbname
definition.
last cvsup of the ports was yesterday and LDAP was defined in
the heimdal port config:
[EMAIL PROTECTED]:/usr/ports/security/heimdal# make showconfig
=== The following configuration options are set for heimdal-0.6.3_2:
LDAP=on Use OpenLDAP as the KDC backend
CRACKLIB=on Use CrackLib for password quality checking
X11=on Build X11 utilies
and indeed it's linked with ldap as you can see:
# ldd /usr/local/sbin/kadmin
/usr/local/sbin/kadmin:
libldap-2.2.so.7 = /usr/local/lib/libldap-2.2.so.7 (0x2812c000)
liblber-2.2.so.7 = /usr/local/lib/liblber-2.2.so.7 (0x2818a000)
when the realm is initied kadmin creates a couple of files with the literal
dbname definition (adding ldap: as filename prefix) instead of contacting
the openldap server.
# /usr/local/sbin/kadmin -l
kadmin init OLIMPUS
Realm max ticket life [unlimited]:
Realm max renewable ticket life [unlimited]:
# ls -l
...
-rw--- 1 root wheel 32768 May 31 10:19 ldap:ou=gods,dc=olimpus.db
-rw--- 1 root wheel 7584 May 31 10:19 ldap:ou=gods,dc=olimpus.log
...
anyone knows what I'm missing?
Thank you.
/-/
# cat /etc/krb5.conf
[libdefaults]
default_realm = OLIMPUS
default_etypes_des = des3-cbc-sha1
default_etypes = des3-cbc-sha1
[appdefaults]
[realms]
OLIMPUS = {
kdc = localhost.olimpus
admin_server = localhost.olimpus
}
[domain_realm]
.olimpus = OLIMPUS
[kdc]
database = {
realm = OLIMPUS
dbname = ldap:ou=gods,dc=olimpus
mkey_file = /var/heimdal/m-key
}
[logging]
kdc = SYSLOG
admin_server = SYSLOG
default = SYSLOG
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mkhomedir.so is missing =(
JP wrote:
I need some help trying to locate or how to obtain/build a file
named mkhomedir.so this file is needed to create home directories
after logging in successfully though winbind. I am running FreeBSD 5.3
Release, and Samba 3. I am unable to locate this file anywhere.
I'm using preexec as a workaround to the missing mkhomedir.
[homes]
comment = Home Directories
valid users = %S
path = /samba/%u
read only = No
browseable = No
# automatic home directories creation
root preexec = if [ ! -d /samba/%u/ ] ;\
then { mkdir -p /samba/%u/.winprofile ;\
chown -R %u /samba/%u ; \
chmod -R 0700 /samba/%u ;} ; \
fi
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Scheduling Issues with Multimedia Apps
Loren M. Lang wrote: Certain tasks that have been doing on FreeBSD like installing ports seem to interrupt my music playing. Particually when portupgrade is extracting/checksumming and when it is updating the package database. Now to try and solve this I tried to set xmms to use realtime priority and made it setuid root. According to top it's running at priority 20 nice -76 so it seems to be running realtime, but portupgrade can still interrupt the audio occasionally. I've tried nicing portupgrade before, but I usually forget, though I'm not even sure if nicing it fixed the problem. I've had this problem with FreeBSD 4.9 to 5.3 on two completely different machines. Also I've had to stop distibuted.net running before because I couldn't play movies with mplayer smoothly. This was on a P4 3.0 GHz, 1G DDR 400 MHz ram. dnet always runs with a nice value of 20 which puts it at about priority 131. Why are these programs able to interrupt my multimedia programs so much. The multimedia programs don't need to use much CPU time with systems as fast as these, but they just need to make sure they get X work done in Y amount of time. If their scheduled apropriately there should be no conflicts, I've never really had this issues with linux, AFAIK. Is there any better way to fix this? I recently read an interview which I think is related with you problem, this is a excerpt: Quote: Getting things out from under Giant has improved performance and interactivity. There still remains however the problem of I/O starvation (eg, the system slows to a crawl while extracting large archives). What can be done about that, and are there plans to do something about it? A large part of the problem is that the vnode system grabs Giant and while that happens nothing much else happens. In essence the entire filesystem arena is single-threaded. The phk_bufwork stuff cuts the bottom bit of this: Today when you get down to the filesystem and it decides to read sector number foo from the disk it asks the vnode system to do so, with phk_bufwork it will send the request to GEOM instead which is a bit faster. But getting the vnode layer more multithreaded is a nasty piece of work which we can just keep chipping away at until we get to the end. read the whole interview: http://forums.bsdnexus.com/viewtopic.php?p=2236 Regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Kenneth Culver wrote: but then why does read/write tests over raw devices performs so bad? AFAIK on raw devices not filesystem, journaling, caches, etc are involved. ___ Like I said before, you might not have been testing the throughput of the disks, instead you may have been testing the throughput of /dev/zero. I woluld like to have the throughput of /dev/zero on my disks. :-) # dd if=/dev/zero of=/dev/null bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 3.414659 secs (314450672 bytes/sec) I'm redirecting this thread to current@ because something seems broken. GNU/Linux 2.4.18 with ext2: 56848 K/sec FreeBSD 5.3b7 with default fs:26347 K/sec FreeBSD 5.3b7 with default fs(async): 26566 K/sec FreeBSD 5.3b7 ata raid0* (two disks): 26131 K/sec FreeBSD 5.3b7 geom stripe* (two disks): 30063 K/sec FreeBSD 5.3b7 geom stripe** (four disks): 31891 K/sec OpenBSD 3.5 UFS fs: 55277 K/sec * Each disk of the raid had a throughput of approx. 15000 K/sec ** Each disk of the raid had a throughput of approx. 7500 K/sec Each disk of the raid split the throughput by half. http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040567.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Kenneth Culver wrote: but then why does read/write tests over raw devices performs so bad? AFAIK on raw devices not filesystem, journaling, caches, etc are involved. ___ Like I said before, you might not have been testing the throughput of the disks, instead you may have been testing the throughput of /dev/zero. I woluld like to have the throughput of /dev/zero on my disks. :-) # dd if=/dev/zero of=/dev/null bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 3.414659 secs (314450672 bytes/sec) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
I'm out of ideas, It doesn't matter if I use other PC or hard disks, performance sucks compared to Linux :-( Any advice or idea about the possible cause? I can't believe this difference of throughput with ata disks.Hello Martin, for linux it took about 23 seconds write the file and 18 read it. # time dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out real0m23.408s user0m0.000s sys0m4.470s # time dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out real0m18.311s user0m0.000s sys0m5.850s and for FreeBSD it took 40 seconds write the file and 42 read it: # dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 40.143630 secs (26747502 bytes/sec) # dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 42.711242 secs (25139560 bytes/sec) so as you can see linux was two times faster that FreeBSD :-? I would like to know if anyone knows if this is normal or is a bug? On linux which filesystem - ext2/ext3/also which kernal/distro vanilla slackware 8.1 with an old 2.4.18 kernel and ext2 filesystem For FreeBSD I presume this was UFS2 rather the UFS, in either case did you enable softupdates? A better 'test' is the bonnie++ utility where you can throw different file sizes etc at the disks, so see what happens with multiple files etc. This gives a more real world view, rather a single file write. I don't think so. I suspect a low level problem. This time I did the test using raw devices instead of block devices, this way filesystem, buffer-cache, softupdates are not present at all. The results were as bad as predicted. # dd if=/dev/zero of=/dev/ad4 bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 38.184851 secs (28119576 bytes/sec) # dd if=/dev/ad4 of=/dev/null bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 31.090536 secs (34535970 bytes/sec) As a curiosity transfers between disk are slower :-? # dd if=/dev/ad4 of=/dev/ad6 bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 69.606197 secs (15425952 bytes/sec) I'm out of ideas, It doesn't matter if I use other PC or hard disks, performance sucks compared to Linux :-( Any advice or idea about the possible cause? I can't believe this difference of throughput with ata disks. # atacontrol list ATA channel 0: Master: ad0 ST340823A/3.32 ATA/ATAPI revision 4 Slave: acd0 HL-DT-ST DVDRAM GSA-4081B/A100 ATA/ATAPI revision 5 ATA channel 1: Master: ad2 ST340810A/5.33 ATA/ATAPI revision 6 Slave: acd1 TOSHIBA DVD-ROM SD-M1612/1004 ATA/ATAPI revision 5 ATA channel 2: Master: ad4 ST340014A/3.54 ATA/ATAPI revision 6 Slave: no device present ATA channel 3: Master: ad6 ST340014A/3.06 ATA/ATAPI revision 6 Slave: no device present # atacontrol mode 2 Master = UDMA100 Slave = BIOSPIO # atacontrol mode 3 Master = UDMA100 Slave = BIOSPIO dmesg: http://lists.freebsd.org/pipermail/freebsd-geom/2004-October/000350.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Hello Martin, for linux it took about 23 seconds write the file and 18 read it. # time dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out real0m23.408s user0m0.000s sys0m4.470s # time dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out real0m18.311s user0m0.000s sys0m5.850s and for FreeBSD it took 40 seconds write the file and 42 read it: # dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 40.143630 secs (26747502 bytes/sec) # dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 42.711242 secs (25139560 bytes/sec) so as you can see linux was two times faster that FreeBSD :-? I would like to know if anyone knows if this is normal or is a bug? On linux which filesystem - ext2/ext3/also which kernal/distro vanilla slackware 8.1 with an old 2.4.18 kernel and ext2 filesystem For FreeBSD I presume this was UFS2 rather the UFS, in either case did you enable softupdates? A better 'test' is the bonnie++ utility where you can throw different file sizes etc at the disks, so see what happens with multiple files etc. This gives a more real world view, rather a single file write. I don't think so. I suspect a low level problem. This time I did the test using raw devices instead of block devices, this way filesystem, buffer-cache, softupdates are not present at all. The results were as bad as predicted. # dd if=/dev/zero of=/dev/ad4 bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 38.184851 secs (28119576 bytes/sec) # dd if=/dev/ad4 of=/dev/null bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 31.090536 secs (34535970 bytes/sec) As a curiosity transfers between disk are slower :-? # dd if=/dev/ad4 of=/dev/ad6 bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 69.606197 secs (15425952 bytes/sec) I'm out of ideas, It doesn't matter if I use other PC or hard disks, performance sucks compared to Linux :-( Any advice or idea about the possible cause? I can't believe this difference of throughput with ata disks. # atacontrol list ATA channel 0: Master: ad0 ST340823A/3.32 ATA/ATAPI revision 4 Slave: acd0 HL-DT-ST DVDRAM GSA-4081B/A100 ATA/ATAPI revision 5 ATA channel 1: Master: ad2 ST340810A/5.33 ATA/ATAPI revision 6 Slave: acd1 TOSHIBA DVD-ROM SD-M1612/1004 ATA/ATAPI revision 5 ATA channel 2: Master: ad4 ST340014A/3.54 ATA/ATAPI revision 6 Slave: no device present ATA channel 3: Master: ad6 ST340014A/3.06 ATA/ATAPI revision 6 Slave: no device present # atacontrol mode 2 Master = UDMA100 Slave = BIOSPIO # atacontrol mode 3 Master = UDMA100 Slave = BIOSPIO dmesg: http://lists.freebsd.org/pipermail/freebsd-geom/2004-October/000350.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Chris Howells wrote: On Friday 15 October 2004 09:57, fandino wrote: I'm out of ideas, It doesn't matter if I use other PC or hard disks, performance sucks compared to Linux :-( OK, so you came to conclusion that performance sucks based on the the theoretical throughput figures using dd and /dev/zero? Why don't you try measuring real world performace, with real files, not somethig which is more than likely completely meaningless when two operating systems cache file system operations in different ways. well, my usage pattern is write a big file and few seconds later read it. So my tests were valid for the use of the computer. But you have reason, I must provide a more formal report. I redid all test with bonnie++ and results shows Linux (56848 K/sec) two times faster than FreeBSD (26347 K/sec) Any help will be appreciated! Linux test (slackware 8.1, kernel 2.4.18, ext2 filesystem): [EMAIL PROTECTED]:/mnt# bonnie++ -s 2048 -u root Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP darkstar 2G 951 97 35108 14 21964 11 1321 99 56848 16 166.4 1 Latency 10024us2203ms 896ms 16845us9552us4118ms Version 1.93c --Sequential Create-- Random Create darkstar-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2413 98 + +++ + +++ 2437 98 + +++ 3822 90 Latency 9366us 37us 67us 18604us 23us 862us FreeBSD 5.3b7 (default filesystem): # bonnie++ -s 2048 -u root Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 194 99 22506 12 10636 7 473 99 26347 11 132.8 7 Latency 59164us 253ms 538ms 37925us 48156us4554ms Version 1.93c --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 762 6 + +++ 1449 8 760 5 + +++ 1417 9 Latency 28352us 226us 22030us 30386us 139us 995us ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Subhro wrote: sysctl -a | grep dma ? vfs.iodmaxidle: 120 vfs.nfs.iodmax: 20 hw.ata.ata_dma: 1 hw.ata.atapi_dma: 1 hw.busdma.free_bpages: 128 hw.busdma.reserved_bpages: 0 hw.busdma.active_bpages: 0 hw.busdma.total_bpages: 128 hw.busdma.total_bounced: 0 hw.busdma.total_deferred: 0 dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.PX40.DMA1 dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 # atacontrol list ATA channel 0: Master: ad0 ST340823A/3.32 ATA/ATAPI revision 4 Slave: acd0 HL-DT-ST DVDRAM GSA-4081B/A100 ATA/ATAPI revision 5 ATA channel 1: Master: ad2 ST340810A/5.33 ATA/ATAPI revision 6 Slave: acd1 TOSHIBA DVD-ROM SD-M1612/1004 ATA/ATAPI revision 5 ATA channel 2: Master: ad4 ST340014A/3.54 ATA/ATAPI revision 6 Slave: ad5 Maxtor 6E040L0/NAR61EA0 ATA/ATAPI revision 7 ATA channel 3: Master: ad6 ST340014A/3.06 ATA/ATAPI revision 6 Slave: ad7 Maxtor 6E040L0/NAR61EA0 ATA/ATAPI revision 7 # atacontrol mode 0 Master = UDMA100 Slave = UDMA33 # atacontrol mode 1 Master = UDMA100 Slave = UDMA33 # atacontrol mode 2 Master = UDMA100 Slave = UDMA100 # atacontrol mode 3 Master = UDMA100 Slave = UDMA100 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and poor ata performance
Kenneth Culver wrote: well, my usage pattern is write a big file and few seconds later read it. So my tests were valid for the use of the computer. But you have reason, I must provide a more formal report. I redid all test with bonnie++ and results shows Linux (56848 K/sec) two times faster than FreeBSD (26347 K/sec) Any help will be appreciated! Linux test (slackware 8.1, kernel 2.4.18, ext2 filesystem): This test isn't really a fair test either. The ext2 filesystem uses async io, and doesn't do any kind of journaling to ensure data integrity in the event of a crash. FreeBSD isn't using async, it uses softupdates. Because of this FreeBSD SHOULD be slower... but it'll be a lot more reliable than linux in the event of a power outage for example. The ext2 filesystem is extremely unreliable, and will almost always lose data when there's a crash or power outage. but then why does read/write tests over raw devices performs so bad? AFAIK on raw devices not filesystem, journaling, caches, etc are involved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD and poor ata performance
Hello list, This is an interesting issue. While I was installing FreeBSD 5.3BETA7 I wonder about the performance that the new branch will bring to my computer, and it was a deception how bad FreeBSD performs compared with Linux on the same hardware (even I repeat the test on different PC with identical results). A simple test is create one gibabyte file and later read this file again. To conduct an impartial test the disk (in UDMA5 mode), was formated in both operating systems with the native filesystem just to be sure that the physical position of the file will be the same in both tests. for linux it took about 23 seconds write the file and 18 read it. # time dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out real0m23.408s user0m0.000s sys0m4.470s # time dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out real0m18.311s user0m0.000s sys0m5.850s and for FreeBSD it took 40 seconds write the file and 42 read it: # dd if=/dev/zero of=aa bs=1024k count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 40.143630 secs (26747502 bytes/sec) # dd if=aa of=/dev/null bs=1024k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 42.711242 secs (25139560 bytes/sec) so as you can see linux was two times faster that FreeBSD :-? I would like to know if anyone knows if this is normal or is a bug? thank you. dmesg: http://lists.freebsd.org/pipermail/freebsd-geom/2004-October/000350.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
