[Bug 195458] Hang on shutdown/root unmount after FreeBSD 10.1R upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 Charley Sheets changed: What|Removed |Added CC||cshe...@nvidia.com --- Comment #17 from Charley Sheets --- I've also just seen this issue. I installed 10.1-RELEASE on an HP ProLiant DL360 G5. After initial configuration, I did a freebsd-update fetch, freebsd-update install, and reboot. Assuming I'm experiencing the same issue as others, it seems to be 10.1 itself and not anything particular to the 10.0 -> 10.1 upgrade, as I did not perform that upgrade. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197286] Panic in IPv6 stack - 0xc0d0b1fc is in ip6_input (/usr/src/sys/netinet6/ip6_input.c:702)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197286 --- Comment #1 from Tim Bishop --- I've confirmed the same issue occurs on stable/9 as well as stable/10. It used to be fine on stable/7 which is what I was using prior to this update. I haven't tested stable/8. However, I've just tried head and so far it looks like this issue is fixed there. There have been a number of changes to the file where the problem occurred, specifically r274300. It'd be good to get these changes MFCed to stable/10 if possible. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197317] Split libncurses into separate libncurses and libtinfo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197317 Bug ID: 197317 Summary: Split libncurses into separate libncurses and libtinfo Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: vmage...@gmail.com Some time ago I (and others as well) have encountered a problem with Python 'curses' module, the solution to which requires a modification to how we build ncurses in base. Here's the background of the problem. 1. Our build scripts for ncurses in base (see lib/ncurses and contrib/ncurses) produce one big library with all the curses functions, libncurses.so, and then symlinks smaller libraries like libtermcap.so and libtinfo.so to libncurses.so. They also produce a Unicode version of that library, libncursesw.so, with a corresponding set of symlinks. 2. Other libraries like libreadline.so (from devel/readline, but previously it was in the base as well), use the 'tgetent' family of functions contained in libtermcap (or libtinfo, which provides those functions as well). Since libtermcap.so is a symlink, libreadline.so gets linked to libncurses.so. 3. Python has a module 'readline' that uses libreadline.so, and another module 'curses' that uses the Unicode version of ncurses, libncursesw.so. Some programs may have both of these modules loaded, which leads to both libncurses.so (through libreadline) and libncursesw.so loaded into the same process. 4. Since both libncurses and libncursesw have identical set of functions, linking to them both may lead to problems. In fact, Python test suite was crashing due to this interaction; for this reason a workaround was added to Python build scripts that checked if libreadline.so is linked with libncurses.so, and if so, it would link Python's 'curses' module with libncurses.so, instead of libncursesw.so. This prevented crashing, but made displaying Unicode text via the 'curses' module impossible. See Python issue 7384 [1] for how this came to pass. Due to all of this, Python's 'curses' module does not display Unicode characters correctly on FreeBSD (see PR 171246 [2] for a test case). The fix for this problem is to split ncurses into separate libtinfo.so (not a symlink!) and libncurses.so, with the latter linking with the former. This is what the upstream ncurses does (also, devel/ncurses). This is also what most Linux distros do, and Python works well in this setup. Note that with this change libncurses.so will still provide the same set of functions, so no regression will occur. Unfortunately we don't use native ncurses build scripts in base, and I don't know how to modify our custom ones to this effect, which is why this PR is without a patch. So, if anyone knows a way to make our build scripts for ncurses to install a separate libtinfo.so, that would be very much appreciated. [1] http://bugs.python.org/issue7384 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171246 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197317] Split libncurses into separate libncurses and libtinfo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197317 Kubilay Kocak changed: What|Removed |Added Keywords||needs-patch, needs-qa CC||b...@freebsd.org See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=1712 ||46 Severity|Affects Only Me |Affects Some People Priority|--- |Normal --- Comment #1 from Kubilay Kocak --- Lovely issue report, thank you for following up on this :) CC'ing bapt since he is quite familiar with our situation with ncurses -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197070] clang fails on attempting to build lang/ruby20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197070 Sevan Janiyan changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Sevan Janiyan --- (In reply to Bjoern Stierand from comment #1) Indeed, adding a swap file resolved the issue. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195990] file: File 5.19 supports only version 12 magic files. `/usr/share/misc/magic.mgc' is version 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195990
Ryder changed:
What|Removed |Added
CC||rt...@columbia.edu
--- Comment #7 from Ryder ---
Minor update: this is still broken for file-5.22 and 10.1-RELEASE-p5.
This also breaks py-magic, which is what led me here.
Try:
>>> import magic
>>> m = magic.open(magic.MAGIC_MIME)
>>> m.load()
Result:
...same errors as with file(1), ending with
/usr/share/misc/magic, 17382: Warning: Printf format `l' is not valid for type
`byte' in description `- version %ld'
Thanks for the workaround. For fixing py27-magic, I can pass it the port
version's magic file instead, like so:
>>> m.load('/usr/local/share/file/magic')
0
>>> m.file('.macromedia')
'inode/directory; charset=binary'
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 187094] [nfs] [patch] FreeBSD DHCP ignores dhcp option interface-mtu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187094 rblay...@inoc.net changed: What|Removed |Added Severity|Affects Only Me |Affects Some People Version|unspecified |10.1-RELEASE -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 187094] [nfs] [patch] Support DHCP option for jumbo frames on PXE/BOOTP interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187094 rblay...@inoc.net changed: What|Removed |Added Summary|[nfs] [patch] FreeBSD DHCP |[nfs] [patch] Support DHCP |ignores dhcp option |option for jumbo frames on |interface-mtu |PXE/BOOTP interface -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197321] syslogd randomly misses forwarding packets to remote host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197321 Bug ID: 197321 Summary: syslogd randomly misses forwarding packets to remote host Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: rblay...@inoc.net Environment: FreeBSD 10.1 amd64 VM instanced on VWMware ESX. NIC driver: vmx VM instances boot as diskless FreeBSD clients. When attempting to forward all syslog data from the clients to a central syslog server on the same network/subnet we randomly see messages NOT make it to the central syslog server. Whats strange is the messages (best we can tell) appear to be almost the same type of message content. /etc/syslog.conf: *.* @10.0.0.110 *.* /var/spool/exim.log Running syslogd in debug: syslogd_flags="-d -ns -v -v" Client machine runs Exim which periodically runs mail queue every 10 minutes. This will generate two syslog messages as seen in the debug: logmsg: pri 26, flags 0, from mxs1, msg Feb 4 16:19:35 exim[98580]: Start queue run: pid=98580 Logging to FORW 10.0.0.110 lsent/l: 59/59 Logging to FILE /var/spool/exim.log logmsg: pri 26, flags 0, from mxs1, msg Feb 4 16:19:35 exim[98580]: End queue run: pid=98580 Logging to FORW 10.0.0.110 lsent/l: 57/57 Logging to FILE /var/spool/exim.log and they do appear in the local logfile on the client server (which was setup just for this test) Feb 4 16:19:35 mxs1 exim[98580]: Start queue run: pid=98580 Feb 4 16:19:35 mxs1 exim[98580]: End queue run: pid=98580 However, we randomly miss the "Start queue ..." message on the central server. This is completely random, sometimes we get it, sometimes we do not. We always seem to receive the "End queue ..." message. After doing a TCP dump with the session above, the TCP dump only shows ONE UDP packet going out, which contained the "End queue..." message, but not the "Start queue..." message. 16:19:24.665116 IP 10.0.0.31.514 > 10.0.0.110.514: SYSLOG mail.info, length: 97 16:19:24.705419 IP 10.0.0.31.514 > 10.0.0.110.514: SYSLOG mail.info, length: 61 16:19:35.342946 IP 10.0.0.31.514 > 10.0.0.110.514: SYSLOG mail.info, length: 57 <== 16:20:24.825348 IP 10.0.0.31.514 > 10.0.0.110.514: SYSLOG mail.info, length: 97 So the message is never generating a packet even though syslogd debug says it it is "logging to FORW 10.0.0.110" This happens about ~40-50% of the time after looking through logs over several hours. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197326] boot0cfg -s does not work unless kern.geom.debugflags=0x10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197326 Bug ID: 197326 Summary: boot0cfg -s does not work unless kern.geom.debugflags=0x10 Product: Base System Version: 9.2-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: marcn...@xiplink.com I've found a bit of back-and-forth on this online, and indeed r227553 says that boot0cfg should not require the debugflags hack. However, I can confirm that it does (this on a recent STABLE 9 build): /root # boot0cfg -v da0 # flag start chs type end chs offset size 1 0x80 0: 2: 1 0xa5 20:254:63 126 337239 2 0x00 21:173: 1 0xa5 42:254:63 348264 342531 3 0x00 43: 89: 1 0xa5 64:254:63 696402 347823 version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F1 (Slice 1) /root # boot0cfg -s 2 da0 /root # boot0cfg -v da0 # flag start chs type end chs offset size 1 0x80 0: 2: 1 0xa5 20:254:63 126 337239 2 0x00 21:173: 1 0xa5 42:254:63 348264 342531 3 0x00 43: 89: 1 0xa5 64:254:63 696402 347823 version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) /root # Note that flag 0x80 is still on partition 1. Even though the default menu selection is partition 2, rebooting at this point will boot partition 1. However, with kern.geom.debugflags=0x10 the active flag moves to partition 2: /root # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 /root # boot0cfg -s 2 da0 /root # boot0cfg -v da0 # flag start chs type end chs offset size 1 0x00 0: 2: 1 0xa5 20:254:63 126 337239 2 0x80 21:173: 1 0xa5 42:254:63 348264 342531 3 0x00 43: 89: 1 0xa5 64:254:63 696402 347823 version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) /root # Some debugging shows that inside boot0cfg's write_mbr() function, the open(O_WRONLY) call returns -1 unless kern.geom.debugflags=0x10. At the very least, boot0cfg should report an error when it fails to update the mbr. Also, r227553 was wrong. IMHO, boot0cfg should be able to update the mbr regardless of the kern.geom.debugflags setting. I understand that others feel differently. Perhaps a compile-time option could be added to let boot0cfg tweak the kern.geom.debugflags automatically? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197326] boot0cfg -s does not work unless kern.geom.debugflags=0x10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197326 --- Comment #1 from Marc Branchaud --- Oops, r227553 is STABLE 9's MFC of r227298. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195484] freebsd-update(8) fails to update 9.2-RELEASE to 10.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195484 m...@tnpi.net changed: What|Removed |Added CC||m...@tnpi.net --- Comment #1 from m...@tnpi.net --- This bug also affects systems upgrading from 9.3-RELEASE -> 10.1-RELEASE. I experienced this at great inconvenience (servers are a continent away) on three systems that I upgraded. Upgrade history: 9.2 -> 9.3 on Aug 13, 2014. 9.1 -> 9.2 on Jan 19, 2014. 9.0 -> 9.1 on Feb 15, 2013. 8.2 -> 9.0 on Aug 7, 2012. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195458] Hang on shutdown/root unmount after FreeBSD 10.1R upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 m...@tnpi.net changed: What|Removed |Added CC||m...@tnpi.net --- Comment #18 from m...@tnpi.net --- I just experienced this as well. It was on a system I just upgraded from 9.3 -> 10.1-RELEASE via the "make world" dance (because of bug #195484 in freebsd-update). Installing the 10.1 kernel and reboot worked fine. Then I installed world, mergemaster, deleted old libs, and finally ran freebsd-update to install the latest security patches. Then it hung on reboot. Ouch. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195458] Hang on shutdown/root unmount after FreeBSD 10.1R upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 --- Comment #19 from m...@tnpi.net --- This seems related. On a server I upgraded to 10.1-RELEASE (via buildworld), and then updated to the latest patch level, I get this in dmesg after boot: Trying to mount root from ufs:/dev/mirror/root [rw]... WARNING: / was not properly dismounted WARNING: / was not properly dismounted -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197267] devd no longer matches kernel/ugen events
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197267 Hans Petter Selasky changed: What|Removed |Added CC||hsela...@freebsd.org --- Comment #2 from Hans Petter Selasky --- Hi, Maybe using "dd if=XXX of=XXX bs=512" is better. What is the maxpacket size of the endpoint in question? --HPS -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197267] devd no longer matches kernel/ugen events
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197267 --- Comment #3 from Hans Petter Selasky --- Hi, I see in your action you hardcode the USB device. Use $cdev instead, and substitute the last digit! action "dd if=/usr/local/share/foo2zjs/firmware/sihp1020.dl of=/dev/usb/1.2.1"; /dev/usb/1.2.1 can be obtained like this in the devd config file: realpath /dev/$cdev | sed -e "s/\.0/.1/g" Address 1.0 does not exist, so the last .0 will always be matched. --HPS -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 193980] [PATCH] OptionalObsoleteFiles.inc missing some SSH and KERBEROS files
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193980 Dmitry Marakasov changed: What|Removed |Added CC||amd...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|amd...@freebsd.org --- Comment #2 from Dmitry Marakasov --- I'm currently working on improving OptionalObsoleteFiles completeness in HEAD, and my changes include these. Will close the bug as soon as changes are MFCd. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197336] find command cannot see more than 32765 subdirectories when using ZFS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197336 Bug ID: 197336 Summary: find command cannot see more than 32765 subdirectories when using ZFS Product: Base System Version: 10.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: wdorm...@gmail.com Created attachment 152566 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152566&action=edit python script to generate a bunch of subdirectories with files in them When a directory has more than 32765 subdirectories in it, the find command fails to find all of the contents if the find command is executed in a ZFS filesystem. If the same command is executed in another filesystem that FreeBSD supports that also supports large counts of subdirectories, the find command sees everything. I've confirmed the correct behavior with both Reiserfs and unionfs. So it appears to be something about the interaction between find and ZFS that triggers the bug. Steps to reproduce: 1. Create a directory structure using the attached dirgen.py script 2. Verify the file count with the ls command. e.g.: ls -lR find_test_q65puW | egrep "txt$" | wc -l 3. Verify the file count with the find command. e.g.: find find_test_q65puW -name "*.txt" | wc -l Actual results: [~/test]$ python ./dirgen.py ndirs: 30 nfiles: 30 [~/test]$ ls -l total 219058 -rw-r--r-- 1 user user 861 Feb 4 15:30 dirgen.py drwx-- 32767 user user32 Feb 4 15:31 find_test_q65puW [~/test]$ ls -lR find_test_q65puW | egrep "txt$" | wc -l 30 [~/test]$ find find_test_q65puW -name "*.txt" | wc -l 32765 The count is not complete. (32765 instead of 30) Expected results: The find command should indicate that there are 30 files. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 Bug ID: 197337 Summary: rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it Product: Base System Version: 10.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: mcdou...@egr.msu.edu I use WITHOUT_KERBEROS on my systems but I still use Kerberos from ports. We also run some Kerberos servers, but Kerberos from ports (at least security/krb5) does not provide startup scripts. The ports depend on the rc.d scripts from the system, such as /etc/rc.d/kdc since you can redefine the daemon path. Fortunately 'make delete-old' does not delete /etc/rc.d/kdc. I think the head/etc/rc.d/Makefile changes in r273285 (head) and r273286 (stable/10) should be reverted as a fix. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 Dmitry Marakasov changed: What|Removed |Added CC||amd...@freebsd.org, ||c...@freebsd.org, ||h...@freebsd.org --- Comment #1 from Dmitry Marakasov --- The solution you propose doesn't seem to be correct - base system and ports should not be dependent on each other this way. Instead, kerberos port should likely be fixed to take care of its rc.d file. CC krb5 and haimdal port maintainers. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197339] [patch] /etc/rc.d/kdc assumes kdc_program is heimdal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197339 Bug ID: 197339 Summary: [patch] /etc/rc.d/kdc assumes kdc_program is heimdal Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: dpej...@yahoo.com Created attachment 152568 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152568&action=edit kdc.patch r270782 changed the kerberos related rc scripts and /etc/rc.d/kdc now always passes '--detach' to the daemon which breaks security/krb5. Previously you could set kerberos5_server="/usr/local/sbin/krb5kdc" kerberos5_flags=" " which would handle the management of the krb5kdc process, but the changes in r270782 will always pass '--detach' to krb5kdc which is an invalid argument. The attached patch restores the previous behavior so you can control the flags passed to the kdc server. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337
Cy Schubert changed:
What|Removed |Added
Status|New |In Progress
--- Comment #2 from Cy Schubert ---
The question is, should /etc/rc.d/kdc be the correct file or should the krb5
ports use their own file? I could argue it both ways but we should look at
existing and prior precedents such as,
- named (when it was still in base), bind9X ports
- sendmail (in base), sendmail (in ports), postfix, exim, etc...
- ntp (in base), ntp (in ports), and ntp-devel
- there are probably others that don't come to mind right now.
I'd like to keep the approach consistent across all classes of software.
Having said that, I can argue for ${LOCALBASE}/etc/rc.d/kdc if all other ports
do the same or if that is our direction. I think a bigger discussion is needed
to set the standard.
Thoughts?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195349] CAM status: Command timeout since upgrade to 10.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195349 --- Comment #33 from David A --- Why is this bug being closed? Not sure if the fix is the patch or the boot loader hint. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #3 from Hiroki Sato --- I also think they should be independent from each other. A port is responsible for installing rc.d scripts if needed. As you noticed, the problem is that collision of the script file name can happen. To solve this, we need a way to select one. I come up with something like the following, but any ideas else? kdc_enable="base" -> enables /etc/rc.d/kdc and ignores /usr/local/etc/rc.d/kdc kdc_enable="pkg" -> ignores /etc/rc.d/kdc and enables /usr/local/etc/rc.d/kdc kdc_enable="YES" -> enables both -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #4 from Cy Schubert --- That seems a bit complex. How about this? Keep the variable names the same for base, e.g., kdc="YES" MIT krb5 ports use, mit_kdc="YES" mit_kadmind="YES" -- adds an entry to crontab for kpropd if mit_kadmind is yes (we assume master runs kadmind thus it also runs kpropd). Heimdal krb5 uses variables prefixed by heimdal_ instead of mit_, for example, heimdal_kdc="YES" There may be a reason to run both simultaneously, but on different ports. (It is possible, with a little work, to have both ports and base heimdal installed on the same system.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #5 from Hiroki Sato --- (In reply to Cy Schubert from comment #4) Do you mean all of the rc.d scripts installed by ports should have their own prefixes to avoid filename collision in a consistent manner? It works for different names such as MIT and Heimdal, but what prefixes are expected for sendmail, for example? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #6 from Cy Schubert --- Sendnail uses mailer.conf. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: [Bug 197336] find command cannot see more than 32765 subdirectories when using ZFS
On Wed, 4 Feb 2015 bugzilla-nore...@freebsd.org wrote:
Created attachment 152566
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152566&action=edit
python script to generate a bunch of subdirectories with files in them
This may be considered a feature -- it detected a bad script that created
too many files
When a directory has more than 32765 subdirectories in it, the find command
fails to find all of the contents if the find command is executed in a ZFS
filesystem.
FreeBSD only supports file systems that support at most 32767 links. This
is mainly a problem for subdirectories, since each subdirectory has a ".."
link to the same parent. It could support at most 65535 links, but this
would break API compatibility, but the API is already broken. More than
that would break binary compatibility. The limit of 65535 is from nlink_t
being 16 bits unsigned, and the limit of 32767 is a bug that has survived
for more than 20 years to keep the API bug for bug compatible.
There are many bugs in this support. Most are in individual file systems.
At the top level, the only know bug is that LINK_MAX is defined at all
(as 32767). Defining it means that the limit {LINK_MAX}, i.e.,
pathconf(path, _PC_LINK_MAX) is the same for all files on all file systems
systems, but FreeBSD supports many file systems with widely varying
{LINK_MAX}.
Some file systems actually implement {LINK_MAX} correctly as the limit
that applies to them:
- this is easy if it is <= LINK_MAX. If it is < LINK_MAX, this is
incompatible with the definition of LINK_MAX, but any software that is
naive or broken enough to use LINK_MAX probably won't notice any problem.
- if it is > LINK_MAX but <= 65535, then returning the correct limit in
pathconf() is again incompatible with LINK_MAX being smaller, and this
now breaks the naive/broken software (e.g., arrays sized with LINK_MAX
may be overrun).
- if it is > 65535, then FreeBSD cannot support the file system properly.
However, if there are no files with more tha 65535 links at mount time,
then it is good enough to maintain this invariant. The python script
should break trying to create the 65536th file in this case (even earlier
on file systems with a smaller limit). If there is just one file with
more than 65535 links, then the file is not supported and perhaps all
operations on it should fail, starting with stat() to see what it is,
since stat() cannot return its correct link count and has no way of
reporting this error except by failing the while syscall.
zfs apparently supports a large number of links, but has many bugs:
- in pathconf() it says that {LINK_MAX} is INT_MAX for all files
- in stat() (VOP_GETATTR()) it breaks this even for files with a link
count between 32768 and 65535 inclusive, by clamping to LINK_MAX
= 32767.
This inconsistency explains the behaviour seen. The python script
might be sophisticated to a fault, but believe the broken {LINK_MAX}.
It might do fancy splitting of subdirectories to avoid hitting the
limit, but not do any splitting since the limit is large. Then
find might be confused by stat() returning the clamped number of
links. I suspect that the actual reasons are more complicated. find
doesn't use link counts much directly, but it uses fts which probably
makes critical use of them.
nfs is much more broken than nfs here. The server file system may
support anything for {LINK_MAX} and st_nlink. nfs seems to blindly
assign the server values (except for {LINK_MAX} in the v2 case, it
invents a value). So if {LINK_MAX} > 65535 on the server, the large
server value is normally returned (not truncated since rlim_t is large
enough for anything). This matches the zfs behaviour of returning a
larger-than-possible value. But if st_nlink > 65535 on the server,
it is blindly truncated to a value <= 65335 (possibly 0, but not
negative since nlink_t is signed. Oops, va_nlink is still short, so
negative values occur too). This is more dangerous than the clamping
in zfs.
nfs mostly uses va_nlink internally, and uses it it in a critical way
for at least the test (va_nlink > 1). Truncation to a signed value
breaks this for all values that were between 32768 and 65535 before
truncation. Truncation to an unsigned value would have only broken
it for 65536, Similarly for all values equal mod 65536 (or 32768).
If the same command is executed in another filesystem that FreeBSD supports
that also supports large counts of subdirectories, the find command sees
everything. I've confirmed the correct behavior with both Reiserfs and
unionfs. So it appears to be something about the interaction between find and
ZFS that triggers the bug.
It is impossible for the other file systems to work much better. Perhaps
they work up to 65535, or have the correct {LINK_MAX} and the python script
is smart enough to avoid it. I doubt that python messes with {LINK_MAX},
but creation of subdirectories should stop when the advertized limit is
h
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #7 from Hiroki Sato --- (In reply to Cy Schubert from comment #6) We are discussing a consistent way to support cases of possible file name collision at this moment and in the future, don't we? I do not think prefixed variables work well for ones like sendmail, ntp, and etc. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #8 from Cy Schubert --- Then we must use a single rc script in /etc/rc.d/. /etc/rc.d/dhclient might be a template. dhclient_enable="YES" dhclient_program="/sbin/dhclient" # Path to dhcp client program. # or dhclient_program="/usr/local/sbin/dhclient" # isc-dhclient dhclient_flags="" etcetera Following this example, our /etc/rc.d/kdc would need to be installed regardless of WITHOUT_KERBEROS as the submitter suggests. To have each port install its own rc.d file in /usr/local/etc/rc.d/ tying into some kind of kdc_enable rules is complex and fragile given multiple ports and base need to adhere to a single set of rules. Putting control and a single set of rules into one rc script (in /etc/rc.d/) will reduce complexity that multiple ports and base will need to adhere to. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 195349] CAM status: Command timeout since upgrade to 10.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195349 --- Comment #34 from Oliver Peter --- Hi David, Both patch and boot loader hint fix the issue for me. I didn't experience any further locks or crashes on my zpools. Steven was so kind to assist me with my issue and we suspect my old SSD and/or crappy cabling causing the timeouts on my side. The boot loader hint restores the previous behaviour, the patch fixes the new behaviour to work properly. Cheers -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
