Re: Strange network/socket anomalies since about a month
Alexander Leidinger writes: > Gleb Smirnoff writes: > > I don't have any better idea than ktrace over failing application. > > Yep, I understand that poudriere will produce a lot. > Yes, it does. 4.4 GB just for the start of poudriere until the first > package build fails due to a failed sccache start [...] Using `ktrace -tcnpstuy` instead of just `ktrace` should greatly reduce the size of the trace file. (remind me to modify ktrace and kdump so this can be written as `-t-i` or `-tI` instead...) DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Unfamiliar console message: in prompt_tty(): caught signal 2
bob prohaska writes: > Apr 20 22:14:37 www su[30398]: in prompt_tty(): caught signal 2 This means someone ran `su` and pressed Ctrl-C instead of entering a password when prompted. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: truss -f timeout 2 sleep 10 causes breakage
Mateusz Guzik writes: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. Confirmed on 14.0-RELEASE-p5. > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep This is sort of expected as truss(1) uses ptrace(2) which breaks the parent-child relationship, so you should never use `truss -f` with a command that expects to control its children. > and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. This, however, is not expected. > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works Neither is this. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Request for Testing: TCP RACK
tue...@freebsd.org writes: > Gary Jennejohn writes: > > In the article we have option TCPHPTS and option TCP_RACK. But in > > /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and > > not option. > Thanks for reporting, that is a typo in the article. It should > always read options instead of option. It's not a typo, both spellings work, cf. config(5). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: noatime on ufs2
Tomek CEDRO writes: > I am reading this interesting discussion and please verify my general > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > access time (atime) because of problem with mailing application? The atime mechanism is considered harmful by many because every file access results in a write which (even if coalesced) not only impacts performance but also increases wear on SSDs. Many people turn it off. Even the FreeBSD installer turns it off when installing to ZFS, except on `/var/mail` which is a separate filesystem precisely so that it can have atime enabled independently of the rest of the system. There is a proposal to turn it off by default. > 2. Linux change of approach to atime that keeps its value only around > last 24h so we should also change it in FreeBSD? > > 3. "realtime" is the alternative solution to keep atime intact? The Linux approach is an alternative mechanism dubbed “relatime” (relative access time) which instead of updating the access time on every access, does so only if the previous atime is either older than the current mtime or more than 24 h ago. > Why change well known standardized and widely used mechanism that is > here for decades? Because it's harmful and most people don't use it. > If there is a problem with an application why change core OS/FS with > all possible negative consequences and not fix the application? There is not “a problem with an application”. No application actually requires atime to function properly because developers knows that atime is a) not universally supported and b) often disabled even when supported. There is however a problem with disk performance and lifetime being degraded. > Wouldn't that break POSIX / backward compatiblity? No. Many people, and the FreeBSD installer, already turn it off. The relatime mechanism would restore atime functionality while causing much less harm, in theory. I'm not sure it would make much difference in practice considering that we have nightly scripts which would trigger atime updates even with relatime. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: compile 13.2p8 on a recent current fails: compiler issue ?
Dimitry Andric writes: > henry vogt writes: > > ===> usr.sbin/zic (obj,all,install) > > Building /usr/obj/usr/src/13.2/amd64.amd64/tmp/obj-tools/usr.sbin/zic/zic.o > > --- zic.o --- > > /usr/src/13.2/contrib/tzcode/zic.c:464:8: error: an attribute list cannot > > appear here > > 464 | static ATTRIBUTE_NORETURN void > > |^~ > This appears to have been fixed upstream some time ago: > https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f It's also fixed in 14 and 15: https://cgit.freebsd.org/src/commit/?id=75411d157232ee3b4789b92c9205453e7d59a3d2 It was too late for 13.2, but I'll make sure it's merged before 13.3. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: issue: poudriere jail update fails after recent changes around certctl
Alexander Leidinger writes: > If FreeBSD provides some certs as trusted (as part of > e.g. installworld), and I have some of them listed in untrusted, I > would not expect an error case, but a failsafe action of not trusting > them and not complaining... am I doing something wrong? No, this is definitely something we want to support. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: issue: poudriere jail update fails after recent changes around certctl
Alexander Leidinger writes: > some change around certctl (world from 2023-10-09) has broken the > poudriere jail update command. The complete install finishes, certctl > is run, and then there is an exit code 1. This is because I have some > certs listed as untrusted, and this seems to give a retval of 1 inside > certctl. This only happens if a certificate is listed as both trusted and untrusted, and I'm pretty sure the previous version would return 1 in that case as well. Can you check? DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: something magic about the size of a ports tree
Warner Losh writes: > Do we support any compression on top of that? Has support for > poudriere been added for it? Yes (zstd) and no. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: something magic about the size of a ports tree
Matthias Apitz writes: > I have on my poudriere build host a ports tree and wanted to move it to > the host where the resulting packages are installed: > > root@jet:/usr/local/poudriere/ports # du -sh ports20230806 > 397Mports20230806 > root@jet:/usr/local/poudriere/ports # tar cf p.tar ports20230806 > root@jet:/usr/local/poudriere/ports # ls -lh p.tar > -rw-r--r-- 1 root wheel 672M Oct 3 18:00 p.tar > > already the size of the tar file is somewhat magic; but if you un-tar it > on the other host I will get: > > [guru@c720-1400094 ~]$ ls -lh p.tar > -rw-r--r-- 1 guru wheel 672M 3 oct. 18:00 p.tar > [guru@c720-1400094 ~]$ tar xf p.tar > [guru@c720-1400094 ~]$ du -sh ports20230806 > 1,2G ports20230806 > > How this is possible? Most files in the ports tree are very small. On disk, each file gets rounded up to the nearest multiple of the filesystem block size, which could be as small as 512 bytes or as large as 8 kB (or even more in pathological cases). In a tarball, they get rounded up to the nearest multiple of 512 bytes plus an additional 512 bytes per file for metadata. For instance, your average distinfo file (of which there are 30k in the ports tree) is only 200-250 bytes long, but it occupies 512 bytes on an FFS filesystem, 1 kB in a tarball, and 4 kB on a typical ZFS filesystem. Note that if the target system is FreeBSD 14 or newer, you can simply mount the tarball (`sudo mount -rt tarfs p.tar /usr/ports`). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char
Mark Millard writes: > I'm not aware of there being other documentation for what > is appropriate for setting up such for kyua runs. https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-test_image-head.sh#L69-L84 DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: sed in CURRENT fails in textproc/jq
Warner Losh writes: > As for memchr, > https://pubs.opengroup.org/onlinepubs/009696799/functions/memchr.html > has no such permission to examine 'the entire buffer at once' nor any > restirction > as to the length extending beyond the address space. I'm skeptical of your > reading > that it allows one to examine all of [b, b + len), so please explain where > the standard > supports reading past the first occurance. C11 says: (7.24.4.1 §2) The memcmp function compares the first n characters of the object pointed to by s1 to the first n characters of the object pointed to by s2. and (7.24.5.1 §2) The memchr function locates the first occurrence of c (converted to an unsigned char) in the initial n characters (each interpreted as unsigned char) of the object pointed to by s. The implementation shall behave as if it reads the characters sequentially and stops as soon as a matching character is found. The second sentence in the description of memchr() means a bogus length is allowed as long as we get a match before we read past the end of the object. There is no such provision for memcmp(), so calling memcmp() with a bogus length invokes UB. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > Unfortunately, here it breaks with: > [...] > /usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 'sys/cdefs.h' > file not found That's because you wiped /usr/obj before starting. Try running 'make buildincludes' inside the buildenv before building libc. If that still fails, just run buildworld; it will fail in libmagic as before but it will have built libc before failing, and you can install libc and restart the build. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > After removing /usr/obj and 'make cleanworld', That was unnecessary. > I tried to build libc like the following, but it fails: > [...] $ cd /usr/src $ make buildenv inside the buildenv, run: $ make -C lib/libc -j$(nproc) then exit the buildenv and run $ sudo make -C lib/libc install then buildworld as usual. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: sed in CURRENT fails in textproc/jq
Antoine Brodin writes:
> Yuri writes:
> > Either something has changed in sed(1) in CURRENT, or sed just fails
> > during the configure stage of textproc/jq:
> >
> > sed: No error: 0
> > checking for sys/cygwin.h... eval: ${+...}: Bad substitution
> This seems to be a recent issue (less than 5 days).
> Hundreds of configure scripts now fail to run on 15-current due to
> this sed failure: [...]
Try adding ARCHLEVEL=scalar to CONFIGURE_ENV on one of these. If that
helps, yell at fuz@ :)
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > If I try to build world from todays c1b26df2972d with 15.0-CURRENT > (main-n265063-e0752f431b01), it aborts with an error. Either update your source tree or apply aca3bd160257, then build and install libc before attempting buildworld. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: sscanf change prevents build of CURRENT
"John F Carr" writes: > I had a problem yesterday and today rebuilding a -CURRENT system from > source: [...] The cause was an sscanf call unexpectedly failing to > parse the input. This caused the mkmagic program (internal tool used > to build magic number table for file) to fail. This was fixed in aca3bd160257. > I am trying to manually compile a working mkmagic and restart the > build to get unstuck. mkmagic is fine, just build and install libc. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes: > c47116e909 with cd25b0f740 and 28d2e3b5de reverted deadlocks, see > attached ddb.txt. I'm going to see if reverting only 28d2e3b5de but not > cd25b0f740 changes anything. c47116e909 with only 28d2e3b5de reverted also deadlocked, but in both cases it took much longer than previously (thousands of pacakges built, rather than hundreds). I'm now going to re-test an unpatched tip-of-tree (4f14d4b6b7), if I can get it to build. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes: > Plot twist: c47116e909 _without_ the patches also appears to be working > fine. The last kernel I know for sure deadlocks is b36f469a15, so I'm > going to test cd25b0f740 and 28d2e3b5de. c47116e909 with cd25b0f740 and 28d2e3b5de reverted deadlocks, see attached ddb.txt. I'm going to see if reverting only 28d2e3b5de but not cd25b0f740 changes anything. DES -- Dag-Erling Smørgrav - d...@freebsd.org ddb.txt.gz Description: Binary data
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes: > A kernel built from c47116e909 plus these two patches has so far built > 2,285 packages without a hitch, whereas normally it would have > deadlocked after well before reaching 500 packages. I'll do another run > without the patches tomorrow just to be sure. Plot twist: c47116e909 _without_ the patches also appears to be working fine. The last kernel I know for sure deadlocks is b36f469a15, so I'm going to test cd25b0f740 and 28d2e3b5de. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Alexander Motin writes: > I don't have a FreeBSD branch, but these two patches apply clean and > build on top of today's FreeBSD main branch: > > https://github.com/openzfs/zfs/pull/15107 > https://github.com/openzfs/zfs/pull/15122 A kernel built from c47116e909 plus these two patches has so far built 2,285 packages without a hitch, whereas normally it would have deadlocked after well before reaching 500 packages. I'll do another run without the patches tomorrow just to be sure. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Alexander Motin writes: > Dag, That's not my name, Al. > Trying to run your test (so far without reproduction) I see it > producing a substantial amount of ZIL writes. The range of commits > you reduced the scope to so far includes my ZIL locking refactoring, > where I know for sure are some deadlocks. I am already waiting for 3 > weeks now for reviews and tests for PR that should fix it: > https://github.com/openzfs/zfs/pull/15122 . It would be good if you > could test it, though it seems to depend on few more earlier patches > not merged to FreeBSD yet. Do you have a FreeBSD branch with your patch applied? DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
The attached script successfully deadlocks 9228ac3a69c4.
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
#!/bin/sh
: ${n:=$(nproc)}
: ${pool:=zroot}
basefs="${pool}/zfsdl"
set -eu
zfs destroy -r "${basefs}" >/dev/null 2>&1 || true
zfs create -o com.sun:auto-snapshot=false "${basefs}"
basedir="$(zfs get -H -o value mountpoint "${basefs}")"
echo "preparing tarball..." >&2
tarball="${basedir}/zfsdl.tar"
mkdir "${basedir}/src"
(cd /usr/src ; find * -type d) | (cd "${basedir}/src" ; xargs mkdir -p)
(cd /usr/src ; find * -type f) | (cd "${basedir}/src" ; xargs touch)
tar cf "${tarball}" -C "${basedir}" src
zfs_deadlock() {
local fs=$1 dir
zfs create "${fs}"
dir="$(zfs get -H -o value mountpoint "${fs}")"
zfs snapshot "${fs}@empty"
while ! [ -f "${basedir}/stop" ] ; do
echo "fill ${fs}..." >&2
tar xf "${tarball}" -C "${dir}"
echo "rollback ${fs}..." >&2
zfs rollback -rR "${fs}@empty"
done
}
for i in $(seq -w "${n}") ; do
zfs_deadlock "${basefs}/${i}" &
sleep 1
done
wait
echo "stop" >&2
zfs destroy -r "${basefs}"
Re: ZFS deadlock in 14
Mateusz Guzik writes: > Going through the list may or may not reveal other threads doing > something in the area and it very well may be they are deadlocked, > which then results in other processes hanging on them. > > Just like in your case the process reported as hung is a random victim > and whatever the real culprit is deeper. We already know the real culprit, see upthread. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Mateusz Guzik writes: > Given that the custom reproducer failed I think the most prudent > course of action is to reproduce again with poudriere, but this time > arrange to have all stacktraces dumped. Why? What more information do you need? DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes: > I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor > 5ca7f02946 appears to be working. I'm going to try to come up with a > more efficient way to reproduce the deadlock than running poudriere. I wrote a script that creates multiple filesystems, snapshots them, populates them and rolls them back continuously but so far I have not succeeded in triggering the deadlock without poudriere. I guess my script doesn't consume enough vnodes. Also, 9228ac3a69c4 (9 August, last commit before the contrib/googletest breakage) still deadlocks. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes: > Trying to narrow this range down, I did not get a deadlock with > 4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June) [...] > Perhaps I should try 4e8d558c9d1c again. I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor 5ca7f02946 appears to be working. I'm going to try to come up with a more efficient way to reproduce the deadlock than running poudriere. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Dag-Erling Smørgrav writes:
> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a
> deadlock was introduced in ZFS.
Trying to narrow this range down, I did not get a deadlock with
4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit
after building ~1800 packages. This is surprising since we have a
report of this or a very similar deadlock occurring with a kernel from 8
June (https://bugs.freebsd.org/271945). Perhaps I should try
4e8d558c9d1c again.
Here's the complete kgdb session showing, once again, a zfs rollback
stuck waiting for the txg to sync:
Reading symbols from /boot/GENERIC/kernel...
Reading symbols from /usr/lib/debug//boot/GENERIC/kernel.debug...
Unread portion of the kernel message buffer:
panic: deadlres_td_sleep_q: possible deadlock detected for
0xfe03567a01e0 (sh), blocked for 180242 ticks
cpuid = 17
time = 1691802362
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe021507ce00
vpanic() at vpanic+0x150/frame 0xfe021507ce50
panic() at panic+0x43/frame 0xfe021507ceb0
deadlkres() at deadlkres+0x350/frame 0xfe021507cef0
fork_exit() at fork_exit+0x80/frame 0xfe021507cf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe021507cf30
--- trap 0xdeadc0de, rip = 0xdeadc0dedeadc0de, rsp = 0xdeadc0dedeadc0de,
rbp = 0xdeadc0dedeadc0de ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) tid 0xfe03567a01e0
(kgdb) bt
#0 sched_switch (td=td@entry=0xfe03567a01e0, flags=flags@entry=259) at
/usr/src/sys/kern/sched_ule.c:2299
#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
/usr/src/sys/kern/kern_synch.c:550
#2 0x80bb1257 in sleepq_switch (wchan=0xf80b139e4770,
wchan@entry=0x8113878f, pri=pri@entry=64) at
/usr/src/sys/kern/subr_sleepqueue.c:609
#3 0x80bb112e in sleepq_wait (wchan=,
pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#4 0x80b21d6f in sleeplk (lk=lk@entry=0xf80b139e4770,
flags=flags@entry=2122752, ilk=ilk@entry=0x0,
wmesg=wmesg@entry=0x8113878f "tmpfs", pri=,
pri@entry=64, timo=timo@entry=6, queue=1) at /usr/src/sys/kern/kern_lock.c:310
#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
flags=2122752, ilk=, file=0x81296919
"/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
/usr/src/sys/kern/kern_lock.c:705
#6 0x80c5e444 in VOP_LOCK1 (vp=0xf80b139e4700, flags=2106368,
file=0x81296919 "/usr/src/sys/kern/vfs_lookup.c", line=1012) at
./vnode_if.h:1120
#7 _vn_lock (vp=0xf80b139e4700, flags=2106368, file=,
line=) at /usr/src/sys/kern/vfs_vnops.c:1808
#8 0x80c36eae in vfs_lookup (ndp=ndp@entry=0xfe03c63a6bd8) at
/usr/src/sys/kern/vfs_lookup.c:1010
#9 0x80c36291 in namei (ndp=ndp@entry=0xfe03c63a6bd8) at
/usr/src/sys/kern/vfs_lookup.c:689
#10 0x80c5681f in kern_statat (td=0xfe03567a01e0,
td@entry=, flag=, fd=-100, path=0x1032a8685a15
,
pathseg=pathseg@entry=UIO_USERSPACE, sbp=sbp@entry=0xfe03c63a6d18)
at /usr/src/sys/kern/vfs_syscalls.c:2441
#11 0x80c56f17 in sys_fstatat (td=, td@entry=, uap=0xfe03567a05e0,
uap@entry=) at
/usr/src/sys/kern/vfs_syscalls.c:2419
#12 0x8104d8e0 in syscallenter (td=) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:190
#13 amd64_syscall (td=0xfe03567a01e0, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1199
#14
#15 0x103acaf3b03a in ?? ()
Backtrace stopped: Cannot access memory at address 0x103ac929af28
(kgdb) f 5
#5 0x80b1fd9f in lockmgr_slock_hard (lk=0xf80b139e4770,
flags=2122752, ilk=, file=0x81296919
"/usr/src/sys/kern/vfs_lookup.c", line=1012, lwa=0x0) at
/usr/src/sys/kern/kern_lock.c:705
705 error = sleeplk(lk, flags, ilk, iwmesg, ipri, itimo,
(kgdb) p (struct thread *)(lk->lk_lock & ~0x1f)
$1 = (struct thread *) 0xfe02ddae0e40
(kgdb) tid 0xfe02ddae0e40
(kgdb) bt
#0 sched_switch (td=td@entry=0xfe02ddae0e40, flags=flags@entry=259) at
/usr/src/sys/kern/sched_ule.c:2299
#1 0x80b5fbd4 in mi_switch (flags=flags@entry=259) at
/usr/src/sys/kern/kern_synch.c:550
#2 0x80bb1257 in sleepq_switch
(wchan=wchan@entry=0xf81ab3c81154, pri=87, pri@entry=-1278734048) at
/usr/src/sys/kern/subr_sleepqueue.c:609
#3 0x80bb112e in sleepq_wait (wchan=,
pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#4 0x80b5f11d in _sleep (ident=0xf81ab3c81154,
lock=0xf81ab3c81120, priority=87, wmesg=0x82239fba "zfs teardown
inactive&qu
Re: Has the update procedure changed?
Tomoaki AOKI writes: > This can help new installation using release tarballs (official or > locally built) or upgrading with overwriting using said tarballs, but > how does freebsd-update? freebsd-update uses the same release process. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Has the update procedure changed?
Tomoaki AOKI writes: > Yes. But if bsdinstall and freebsd-update automatically bootstrap > etcupdate if not yet done, newbies and casual users wouldn't be bitten. https://cgit.freebsd.org/src/commit/?id=e9120a256075543376496fbd75949eed1f13a887 DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ZFS deadlock in 14
Alan Somers writes: > Do you have ZFS block cloning enabled on your pool? There were a lot > of bugs associated with that feature. I think that was merged on > 3-April. No, and this deadlock did not appear until May. DES -- Dag-Erling Smørgrav - d...@freebsd.org
ZFS deadlock in 14
#14959 ZIL: Fix race introduced by f63811f0721
Obtained from: OpenZFS
OpenZFS commit: feff9dfed3df1bbae5dd74959a6ad87d11f27ffb
commit b7198dcfc03967cba191a373d99df47ee52d6e2a
Merge: 2c7279bae776 10e36e17612b
Author: Martin Matuska
AuthorDate: Fri Jun 16 23:12:27 2023 +0200
Commit: Martin Matuska
CommitDate: Fri Jun 16 23:13:05 2023 +0200
zfs: merge openzfs/zfs@10e36e176
Notable upstream pull request merges:
#14948 Remove ARC/ZIO physdone callbacks
#14963 Store the L2ARC device ashift in the vdev label
#14970 Switch refcount tracking from lists to AVL-trees
#14981 Shorten arcstat_quiescence sleep time
Obtained from: OpenZFS
OpenZFS commit: 10e36e17612ba9c634b140ae76847bb62b5be68f
commit f190c36b5d45cbfadc922a69d79628c43cdda22f
Merge: 229d643c4dd5 8e8acabdcaeb
Author: Martin Matuska
AuthorDate: Sun Jun 25 10:31:19 2023 +0200
Commit: Martin Matuska
CommitDate: Sun Jun 25 10:32:42 2023 +0200
zfs: merge openzfs/zfs@8e8acabdc
Notable upstream pull request merges:
#14987 Fix memory leak in zil_parse()
Obtained from: OpenZFS
OpenZFS commit: 8e8acabdcaeb831c777f71361722f4235b698a8d
We can't ship 14.0 with this deadlock.
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Re: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?
Michael Grimm writes: > I'm currently in the process to prepare for upcoming 14-STABLE. Thus, > I upgraded one of my sytems from 13-STABLE to 14-CURRENT. Did you run etcupdate? DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Has the update procedure changed?
Matthias Apitz writes: > I know the reason (the install process uses the old existing kldxref which > does > not can handle some things). I proceeded with the installation and all > is fine, the box is up again in multiuser and /usr/sbin/kldxref is now > from today. Should I run 'make installkernel' a 2nd time? 'make reinstallkernel' is more appropriate in this case. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Surprise null root password
David Chisnall writes: > There was a very nasty POLA violation a release or two ago. OpenSSH > defaults to disallowing empty passwords and so having a null password > was a convenient way of allowing people to su or locally log into that > user but disallowing ssh. This option does not work in recent > versions of FreeBSD. Turning on the option to permit root login while > keeping the root password blank used to be (mostly) safe because it > permitted su to root from people in the wheel group, root login via > SSH key remotely (for ‘everything is broken I can’t log in as a user > whose home directory is not on the root filesystem’ recovery) and > local login as root from consoles marked as secure. It now permits > root login from the network with a blank password. That is incorrect. PermitRootLogin defaults to “no” in FreeBSD and to “prohibit-password” upstream (and presumably in the port), while PermitEmptyPasswords defaults to “no” both in FreeBSD and upstream, cf. crypto/openssh/servconf.c (search for “permit_root” and “permit_empty”). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
FreeBSD User writes: > I tried to put the option > > WITHOUT_MODULE="an" it's spelled WITHOUT_MODULES, cf. make.conf(5). DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: cant login after make installworld: pam_opie.so.6 not found
Ivan Quitschal writes: > I had to "install" the new temporary /etc/pam.d files with mergemaster. I > think the problematic file was > the "system" config file. Now its all fine If you wish to continue to use OPIE (which I don't recommend), there is now a port (security/opie). You will have to manually add back the pam_opie and pam_opieaccess lines in the relevant PAM policies. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Putting OPIE to rest
grarpamp writes: > OPIE is the only PAM that allows printing out the future > secure tokens. Old school, secure, it just works. > > HOTP requires hardware, TOTP requires time, > neither are printable, both of those require some other > [hackable] hw/sw device that costs $$$ money, and > those devices all have different threat/failure/admin models > than simple paper. Neither HOTP nor TOTP require dedicated devices. HOTP codes are sequential and can be pre-generated and printed if that's what you prefer. DES -- Dag-Erling Smørgrav - d...@des.no
Putting OPIE to rest
I will be removing OPIE from the main branch within the next few days. It has long outlived its usefulness. Anyone still using it should look into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). https://reviews.freebsd.org/D36592 DES -- Dag-Erling Smørgrav - d...@des.no
Re: Dragonfly Mail Agent (dma) in the base system
Baptiste Daroussin writes: > Dag-Erling Smørgrav writes: > > [...] does not have a default domain setting, so it cannot handle > > email from cron, periodic etc. where the recipient is just a user > > name (usually “root”) [...] > This has been fixed since. (not by me) In that case, assuming that it behaves sensibly out of the box, my only objection is the lack of documentation, which I understand is being worked on. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste writes: > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. It cannot. Ask bapt@ who was the one to import it, and later abandon the idea of making it our default MTA. The reason was that it does not have a default domain setting, so it cannot handle email from cron, periodic etc. where the recipient is just a user name (usually “root”), and the devs were not willing to add that feature. I have email as far back as 2015 on the subject. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Yuri Pankov writes: > There's apparently a bug in VMware Workstation NAT implementation, > [...] The patch itself is attached. Could you please open a differential and add me as reviewer? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. I don't speak for them, but I assure you that both their code and ours are full of workarounds for bugs in third-party software and hardware, and it is ridiculous to claim otherwise. > No. We do like Red Hat does. Advise the customer to use a workaround > until the other vendor fixes their code. With respect, that's not your decision. It's mine. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > I know our code is full of workarounds and theirs probably too. The > question is should we? IMO no. Unfortunately, the world is imperfect and does not care about your opinion. 90% of the hardware we run on deviates from the spec in some way or another and requires workarounds in the kernel. We even have a whole system of quirks for disks and USB devices. Libfetch contains workarounds for buggy HTTP servers. OpenSSH has hundreds of lines of code devoted to identifying the server and selecting workarounds to apply. Without those workarounds, FreeBSD would not be a viable piece of software. Wishing they weren't needed is a waste of time and energy. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. It's something we do *all the time*. Otherwise we'd just be a toy OS that hobbyists played with in the weekends on an old spare machine they keep in a basement closet. > If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. Then it's useless. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Devd / devmatch(8) -- netif race 12-RC1
Warner Losh writes: > coretemp is a CPU device, and so I'm not sure we have the right PNP > information for the CPU bus for it to even load. The coretemp device is not really a device, it's just a couple of MSRs. As such, it is not attached to an enumerable bus, or any bus at all that devd's aware of. The only way to find out if it's supported is to call the driver's identify method, which checks the cpuid and creates a device instance for each reported sensor. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1
Rebecca Cran writes: > After installing 12.0-BETA1, on the first boot I noticed a warning > about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set it to “no”) and let me know if it helps? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: careless commits disrupt
"Julian H. Stacey" writes: > Stefan Esser writes: > > I might have mentioned, that I always preserve old shared libraries > > in /usr/lib/compat before running "make delete-old-libs". > Good idea, are you doing that manually, or do you have a patch to > share ? # pkg install -y misc/compat9x misc/compat10x misc/compat11x DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
Jung-uk Kim writes: > I forgot to patch one more file, i.e., Makefile.inc1. Please try the > attached patch instead. Thanks, I missed that too. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: careless commits disrupt
Julian H. Stacey writes: > Stefan Esser writes: > > You should also delete old files: > > > > cd /usr/src > > make delete-old > > make delete-old-libs > I just ran that. It deleted lots of stuff. & I'd only run it 2 days ago. > I should have run it just before buildworld though. > It's not suggested in the top of > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > just at base of page. That's because you should *never* run delete-old or delete-old-libs from a source tree that is newer than your installed system. It may delete files which have been obsoleted by changes you haven't yet built and installed, to the point where you may be unable to build and install those changes. In this particular case, it will, at the very least, break ssh and svn / svnlite. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
Glen Barber writes: > Justin Hibbits writes: > > Seems r339303 is the cuplrit. Reverting this gets my build completing. > Justin, thanks for identifying the commit in question. DES, can you > take a look at this? It's a bit complicated because there are two separate issues here. Alex, Julian and others are seeing linker failures in libcrypto, long before libldns. I have the exact same issue on i386 but not amd64; I haven't been able to build world on i386 since openssl111 was merged to head, before any of my LDNS and Unbound commits. I assumed that it was a local problem, but now several people are seeing the same thing. Justin is seeing a linker failure in libldns which is probably related to my commit, but which I am unable to reproduce. I hope that r339325 will fix it. The question is, why did it break everything *but* amd64? I think a build system expert is needed here. (and libldns probably needs a version bump, but that won't affect this) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r339216 breaks ssh to i386 devices
Michael Butler writes: > Marek Zarychta writes: > > I have connected serial console to affected box and upgraded system > > from patched sources. I am sorry to say that this patch doesn't > > solve the issue for 32-bit ARM (RPi2). Still sshd terminates session > > with the error "fatal: mm_getpwnamallow: receive get struct passwd > > failed [preauth]". > My experience is similar - there maybe another 32/64-bit issue :-( Correct, there is a size_t being passed as as an u64 as well. That explains why arm32 was broken too, and not just i386. The quick fix is to replace size_t with u_int64_t in sshbuf_get_passwd(), on line 513 of sshbuf-getput-basic.c (with my previous patch applied). I have a full patch in the pipeline. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r339216 breaks ssh to i386 devices
Please try the attached patch. I expect it to fix i386. If it also
fixes arm32, all the better, although I don't quite see why it would.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: crypto/openssh/sshbuf-getput-basic.c
===
--- crypto/openssh/sshbuf-getput-basic.c (revision 339244)
+++ crypto/openssh/sshbuf-getput-basic.c (working copy)
@@ -482,7 +482,9 @@
(r = sshbuf_put_cstring(buf, "*")) != 0 ||
(r = sshbuf_put_u32(buf, pwent->pw_uid)) != 0 ||
(r = sshbuf_put_u32(buf, pwent->pw_gid)) != 0 ||
- (r = sshbuf_put_u64(buf, pwent->pw_change)) != 0 ||
+#ifdef HAVE_STRUCT_PASSWD_PW_CHANGE
+ (r = sshbuf_put_time(buf, pwent->pw_change)) != 0 ||
+#endif
#ifdef HAVE_STRUCT_PASSWD_PW_GECOS
(r = sshbuf_put_cstring(buf, pwent->pw_gecos)) != 0 ||
#endif
@@ -491,7 +493,9 @@
#endif
(r = sshbuf_put_cstring(buf, pwent->pw_dir)) != 0 ||
(r = sshbuf_put_cstring(buf, pwent->pw_shell)) != 0 ||
- (r = sshbuf_put_u64(buf, pwent->pw_expire)) != 0 ||
+#ifdef HAVE_STRUCT_PASSWD_PW_EXPIRE
+ (r = sshbuf_put_time(buf, pwent->pw_expire)) != 0 ||
+#endif
(r = sshbuf_put_u32(buf, pwent->pw_fields)) != 0) {
return r;
}
@@ -518,7 +522,9 @@
sshbuf_get_cstring(buf, >pw_passwd, NULL) != 0 ||
sshbuf_get_u32(buf, >pw_uid) != 0 ||
sshbuf_get_u32(buf, >pw_gid) != 0 ||
- sshbuf_get_u64(buf, >pw_change) != 0 ||
+#ifdef HAVE_STRUCT_PASSWD_PW_CHANGE
+ sshbuf_get_time(buf, >pw_change) != 0 ||
+#endif
#ifdef HAVE_STRUCT_PASSWD_PW_GECOS
sshbuf_get_cstring(buf, >pw_gecos, NULL) != 0 ||
#endif
@@ -527,7 +533,9 @@
#endif
sshbuf_get_cstring(buf, >pw_dir, NULL) != 0 ||
sshbuf_get_cstring(buf, >pw_shell, NULL) != 0 ||
- sshbuf_get_u64(buf, >pw_expire) != 0 ||
+#ifdef HAVE_STRUCT_PASSWD_PW_EXPIRE
+ sshbuf_get_time(buf, >pw_expire) != 0 ||
+#endif
sshbuf_get_u32(buf, >pw_fields) != 0) {
sshbuf_free_passwd(pw);
return NULL;
Index: crypto/openssh/sshbuf.h
===
--- crypto/openssh/sshbuf.h (revision 339244)
+++ crypto/openssh/sshbuf.h (working copy)
@@ -177,6 +177,14 @@
int sshbuf_put_u16(struct sshbuf *buf, u_int16_t val);
int sshbuf_put_u8(struct sshbuf *buf, u_char val);
+#if defined(__FreeBSD__) && defined(__i386__)
+#define sshbuf_get_time(b, vp) sshbuf_get_u32((b), (u_int32_t *)(vp))
+#define sshbuf_put_time(b, v) sshbuf_put_u32((b), (u_int32_t)(v))
+#else
+#define sshbuf_get_time(b, vp) sshbuf_get_u64((b), (u_int64_t *)(vp))
+#define sshbuf_put_time(b, v) sshbuf_put_u64((b), (u_int64_t)(v))
+#endif
+
/*
* Functions to extract or store SSH wire encoded strings (u32 len || data)
* The "cstring" variants admit no \0 characters in the string contents.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r339216 breaks ssh to i386 devices
Marek Zarychta writes: > Michael Butler writes: > > With an i386 system, ssh sessions to the updated sshd fail with: > > > > sshd[28771]: fatal: mm_getpwnamallow: receive get struct passwd failed > > [preauth] > > > > This is reproducible on both real hardware and in a VM running an i386 > > build, > sshd running on 32-bit ARM architecture seems to be also affected after > update to 12.0-ALPHA8 r339223. r339216 introduced some code which assumes that time_t is always 64 bits wide, which is not the case for i386. I'm not 100% that's the cause, as it shouldn't break arm32, where time_t *is* 64 bits wide, but it still needs fixing. Are you getting the exact same error message as Michael? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
blubee blubeeme writes: > You seem to miss the point where the you avoid breaking the system for > any users not on the bleeding edge. You seem to miss the point where nobody is interested in anything you have to say any more. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head's /usr/src/UPDATING vs. "LOADER_DEFAULT_INTERP, documented in build(7)": not documented yet
Mark Millard writes: > But when I look at [...] the installed build(7) for head -r338319 I do > not find any references to LOADER_DEFAULT_INTERP . It was added to build(7) in r338043: LOADER_DEFAULT_INTERP Defines what interpreter the default loader program will have. Valid values include “4th”, “lua”, and “simp”. This creates the default link for /boot/loader to the loader with that interpreter. It also determines what interpreter is compiled into userboot. > I have assumed that my long-in-use amd64 virtual-box context that I > run and update FreeBSD in (under macOS) just automatically updated > sufficiently via installkernel and installworld after building. Correct. The loader and its support files (4th and lua) are built by 'make buildworld' and installed by 'make installworld'. The source code is in /usr/src/stand. > (This assumes that all the changes are in the freebsd-ufs partition > involved and that the freebsd-boot partition involved need not be > updated.) The freebsd-boot partition contains the code that loads the loader and should not need updating. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
blubee blubeeme writes: > Hans Petter Selasky writes: > > Are you here to try to stir a conflict? If so that is not > > appreciated. > Hans, you of all people should know that's not true. And yet here we are. You have made it perfectly clear that you are not interested in an honest discussion. Your entire strategy is to wear people down until they either leave or agree with you just to shut you up. Like Hans Petter says, it is not appreciated. You clearly believe that you know better than anyone else how this should be handled, so instead of telling us, I suggest you just go do it. It only takes seconds to fork the FreeBSD mirror on Github, and a few minutes to clone it onto your machine. We look forward to hearing from you again when you have everything working perfectly and seamlessly out of the box for everybody on any equipment. I'm sure that Johannes, Niclas, Warner and others with a century of combined experience will be thrilled to see you succeed where they, by your account, have failed. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
blubee blubeeme writes: > True on both points my tone is just a reflection of attitudes of the > individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. > Some people enjoy making contributions w/o waving a banner constantly > wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. > How far will core FreeBSD bend over backwards to accommodate these > devs. The core team does not decide what goes into the tree or not. The developers do. > This is the beauty of an open source project, we bring the best to the > table, [...] Who exactly is “we” here? You are not a member of the project, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Miroslav Lachman <000.f...@quip.cz> writes: > Bryan Drewery <bdrew...@freebsd.org> writes: > > https://github.com/freebsd/pkg/blob/master/scripts/pkg_tree.sh > Can you publish it as a port? I know there is one written in Perl but > I like your sh without dependencies. It's not very useful, in my opinion. The relationships between packages form a directed acyclic graph, not a tree, so pkg_tree.sh will either show too little (without -r) or far, far too much (with -r). If you want to visualize the package graph, you can feed the output of 'pkg query "%n %dn"' into something like graphviz. For other tasks, you are better off learning how to use 'pkg query' and possibly creating your own aliases or scripts. It's not that difficult; feel free to ask for help. (Just for kicks, I tried running 'pkg_tree.sh -rn' on my desktop, which has 934 packages installed. It's been running for ten minutes and has printed over 90,000 lines, with no end in sight.) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Daniel Eischen <deisc...@freebsd.org> writes: > It would be nice to have pkg(8) show packages in tree form, with option > to show just top-level meta packages or packages that have no meta. Packages not marked as automatically installed: # pkg query -e '%a == 0' %n-%v Packages with no reverse dependencies: # pkg query -e '%#r == 0' %n-%v DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> Can you do some small discurs about ssh+kerberos?
> I am try to use FreeBSD with $HOME over kerberoized NFS.
> For kerberoized NFS gssd need to find cache file "called
> /tmp/krb5cc_, where is the effective uid for the RPC
> caller" (from `man gssd`).
>
> sshd contrary create cache file for received ticket called
> /tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
> this strong security requirement or [FreeBSD/upstream] can be patched
> (or introduce option) to use /tmp/krb5cc_ as cache file for
> received ticket?
I wasn't aware of that. It should be easy to patch, but in the
meantime, you can try something like this in .bashrc or whatever:
krb5cc_uid="/tmp/krb5cc_$(id -u)"
if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
export KRB5CCNAME="${krb5ccuid}"
else
echo "Unable to rename krb5 credential cache" >&2
fi
fi
unset krb5ccuid
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
Slawa Olhovchenkov <s...@zxy.spb.ru> writes: > Dag-Erling Smørgrav <d...@des.no> writes: > > In the meantime, you can try something like this in .bashrc or > > whatever: > Imposible. For accessing .bashrc on kerberoized NFS need correct > /tmp/krb5cc_. /etc/profile, then. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
Slawa Olhovchenkov <s...@zxy.spb.ru> writes: > OK, what about tcsh, zsh, fish and scp/sftp? I apologize for trying to help you out by suggesting a hack that works at least some of the time until I can get a permanent fix in. I should instead have hopped in my time machine, jumped back a few years, and fixed the bug before it affected you. No hard feelings? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
Julian Elischer <jul...@freebsd.org> writes: > what is the internal window size in the new ssh? 64 kB. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
Kevin Oberman <rkober...@gmail.com> writes: > Dag-Erling Smørgrav <d...@des.no> writes: > > Julian Elischer <jul...@freebsd.org> writes: > > > what is the internal window size in the new ssh? > > 64 kB. > Are you sure of this? Sorry, I was thinking of 6.6 (in stable/10). The buffer code in 7.1 supports dynamically-sized buffers with a hard limit of 128 MB. The default window size for client sessions is 2 MB, or 1 MB if associated with a tty. I'm not sure what the maximum size is. Note that scp, sftp etc. count as client sessions. X11 and agent forwarding use different (smaller) windows which improve latency at the cost of throughput. > [...] scp still performed poorly when compared to other technologies scp is a horrible protocol, use sftp or (preferably) rsync over ssh. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HPN and None options in OpenSSH
The HPN and None cipher patches have been removed from FreeBSD-CURRENT. I intend to remove them from FreeBSD-STABLE this weekend. The HPN patches were of limited usefulness and required a great deal of effort to maintain in our tree. The None cipher patch was less onerous, but it was a terrible idea with a very small user base since it was a compile-time option and off by default. The HPN-related configuration variables have been marked deprecated, while those related to the None cipher have been marked unsupported. This means that the former will be accepted with a warning, whereas the latter will result in an error. Most users will not be affected by this change. Those who are should switch to the openssh-portable port, which still offers both patches, with HPN enabled by default. It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a number of modifications intended to reduce the impact of upstream changes on existing systems. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken
Maxim Sobolev <sobo...@freebsd.org> writes: > Hi, while working on some unrelated feature I've noticed that at least > those two system calls are not returning proper value (-1) on error. > Instead actual errno value is returned from the syscall verbatim, > i.e. posix_fadvise() returns 22 on EINVAL. That's how syscalls work. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken
Konstantin Belousov <kostik...@gmail.com> writes: > Dag-Erling Smørgrav <d...@des.no> writes: > > Maxim Sobolev <sobo...@freebsd.org> writes: > > > Hi, while working on some unrelated feature I've noticed that at least > > > those two system calls are not returning proper value (-1) on error. > > > Instead actual errno value is returned from the syscall verbatim, > > > i.e. posix_fadvise() returns 22 on EINVAL. > > That's how syscalls work. > No, this is not how typical syscalls work, but is how the posix_fallocate() > and posix_fadvise() are specified by Posix. The patch is wrong, see also > r261080 and r288640. Umm, I can't find the code ATM but syscalls store the actual return value in td_retval and return 0 or EWHATEVER and the syscall wrapper handles the translation. If that's not what Maxim was talking about, then please ignore me. Anyway, happy to hear that the X/Open group have found a new way to screw people over. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Bryan Drewery <bdrew...@freebsd.org> writes: > It's harder to maintain the port version due to how the patches are > applied and generated. I have the diametrically opposite experience. The workflow for ports is significantly simpler than for base. Perhaps I should set up a paralell workflow for OpenSSH and apply the output of that workflow to the source tree instead of working entirely within the source tree. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Benjamin Kaduk <ka...@mit.edu> writes: > Things seem to have slowed down a lot since the lead Heimdal developer > got hired for Apple. [...] MIT employs developers whose job > descriptions include being the krb5 release manager [...] Heimdal has > changed plans to a 1.7 release [...] and since the developers in > question are being paid to work on other things, there is no real > timeline for the release. Given this state of affairs, it might not be unreasonable to consider switching back for 11. There should be enough time, provided our Kerberos maintainers have some spare cycles. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Bryan Drewery <bdrew...@freebsd.org> writes: > Actually I am missing the client-side VersionAddendum support (ssh.c). I > only have server-side (sshd.c). This is just due to lack of motivation > to import the changes. Pretty sure I sent Damien the patch a few years ago... There was also a bug in the server-side code (IIRC, one place where it printed only the hardcoded version instead of the variable string). I'll try again. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Daniel Kalchev <dan...@digsys.bg> writes: > I must have missed the explanation. But why having a NONE cypher > compiled in, but disabled in the configuration is a bad idea? It increases the cost of maintaining OpenSSH in base noticeably without providing real value unless you are one of the few people who need HPN and lack the CPU power to perform encryption at line speed. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Slawa Olhovchenkov <s...@zxy.spb.ru> writes: > Can you explain what is problem? Radical suggestion: read the first email in the thread. > PS: As I today know, kerberos heimdal is practicaly dead as opensource > project. Have FreeBSD planed switch to MIT Kerberos? I am know about > security/krb5. We switched from MIT to Heimdal at some point in the past for some reason I don't remember. MIT and Heimdal are *not* interchangeable at the source or binary level, so switching back is not trivial. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Bryan Drewery <bdrew...@freebsd.org> writes: > Another thing that I did with the port was restore the tcpwrapper > support that upstream removed. Again, if we decide it is not worth > keeping in base I will remove it as default in the port. I want to keep tcpwrapper support - it is another reason why I still haven't upgraded OpenSSH, but to the best of my knowledge, it is far less intrusive than HPN. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Julian Elischer <jul...@freebsd.org> writes: > Bob Bishop <r...@gid.co.uk> writes: > > Is removing HPN going to impact the performance of tunnelled X > > connexions? > yes if your rtt is greater than about 85 mSec With an RTT of 85 ms, X is unusable with or without HPN. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Julian Elischer <jul...@freebsd.org> writes: > Now we'll have to resurrect all that framework and pain. I guess pain is fine as long as it's not yours... > have you mentioned this plan to Brooks? Didn't he add it? These are public lists, but by all means, mention it to him if he hasn't noticed this thread. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Ben Woods <woods...@gmail.com> writes: > Personally I have used it at home to backup my old FreeBSD server > (which does not have AESNI) over a dedicated network connection to a > backup server using rsync/ssh. Since it was not possible for anyone > else to be on that local network, and the server was so old it didn't > have AESNI and would soon be retired, using the NONE cipher sped up > the transfer significantly. In that scenario, you don't need ssh at all. Just set up rsyncd on the backup server. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Julian Elischer <jul...@freebsd.org> writes: > The inclusion of the HPN patches meant that we could drop a custom > unsupported HPN enabled ssh from our build process. It makes ssh > actually usable. Define "usable". Does it actually make a measurable difference with the latest OpenSSH? And if HPN is so important to you, is there a reason why you can't use the port? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
OpenSSH HPN
Some of you may have noticed that OpenSSH in base is lagging far behind the upstream code. The main reason for this is the burden of maintaining the HPN patches. They are extensive, very intrusive, and touch parts of the OpenSSH code that change significantly in every release. Since they are not regularly updated, I have to choose between trying to resolve the conflicts myself (hoping I don't break anything) or waiting for them to catch up and then figuring out how to apply the new version. Therefore, I would like to remove the HPN patches from base and refer anyone who really needs them to the openssh-portable port, which has them as a default option. I would also like to remove the NONE cipher patch, which is also available in the port (off by default, just like in base). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Willem Jan Withagen <w...@digiware.nl> writes: > I know I've installed the ports once to see if, and how I would be > able to add more IP-address infor to some of the warnings and > errors. And then to get thos errors recognised by tools like sshguard > and fail2ban. Do you mean logging IP addresses instead of hostnames? Just turn off UseDNS. It is off by default since 6.8. If you mean adding IP addresses or hostnames to messages that don't already have them, try suggesting it on the openssh-portable mailing list (openssh-unix-...@mindrot.org). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Willem Jan Withagen <w...@digiware.nl> writes: > Digging in my logfiles , and its things like: > sshd[84942]: Disconnecting: Too many authentication failures [preauth] > > So errors/warnings without IP-nr. > > And I think I fixed it on one server to also write: > error: maximum authentication attempts exceeded for root from > 173.254.203.88 port 1042 ssh2 [preauth] fail2ban should catch both of these since sshd will print a message for each failed authentication attempt before it prints a message about reaching the limit. > Are they still willing to accept changes to the old version that is > currently in base? No, why would they do that? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Willem Jan Withagen <w...@digiware.nl> writes: > "Dag-Erling Smørgrav" <d...@des.no> writes: > > Willem Jan Withagen <w...@digiware.nl> writes: > > > Are they still willing to accept changes to the old version that > > > is currently in base? > > No, why would they do that? > Exactly my question I guess I misinterpreted your suggestion on > upstreaming patches. I didn't suggest submitting patches, I suggested submitting a feature request. Damien is generally pretty open to suggestions. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
Bob Bishop <r...@gid.co.uk> writes: > Is removing HPN going to impact the performance of tunnelled X > connexions? I don't think so. It mostly affects the performance of long unidirectional streams (file transfers) whereas the X protocol, as far as I know, is a bidirectional exchange of relatively short messages. It may make a difference for applications that transfer large textures... I don't really know enough about the X protocol to say for certain, but I am typing this in Emacs over a non-HPN SSH connection, and I regularly tunnel Firefox between the same two machines (RHEL 7 desktop at work and FreeBSD 10 desktop at home). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
NGie Cooper <yaneurab...@gmail.com> writes: > Dag-Erling Smørgrav <d...@des.no> writes: > > David Wolfskill <da...@catwhisker.org> writes: > > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > > Did you find a solution? [...] > https://svnweb.freebsd.org/changeset/base/287591 ? Are you certain? The commit message does not mention David or ntpd. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
David Wolfskill <da...@catwhisker.org> writes: > ... > bound to 172.17.1.245 -- renewal in 43200 seconds. > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped) > Starting Network: lo0 em0 iwn0 lagg0. > ... Did you find a solution? I'm wondering if the ntpd problems people are reporting on freebsd-security@ are related. I vaguely recall hearing that this had been traced to a pthread bug, but can't find anything about it in commit logs or mailing list archives. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segmentation fault running ntpd
Franco Fichtner <fra...@lastsummer.de> writes: > Well, it’s on stable/10 since September 16 and somebody reported that > this particular branch would not trigger the crash along with HEAD, > but any 10.x would. Can’t find the reference right now though. OK, we should do an EN with that patch then, but we may have to include some of the other recent commits to the vm_map.c, which seem (at a quick glance) to be related. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrade to Unbound 1.5.1 incomplete?
Jung-uk Kim j...@freebsd.org writes: A file seems missing. I worked around it like this: sed -e 's/@ENABLE_DNSTAP@/0/' \ /usr/src/contrib/unbound/dnstap/dnstap_config.h.in \ /usr/src/contrib/unbound/dnstap/dnstap_config.h Thank you, fixed. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Dag-Erling Smørgrav d...@des.no writes: Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFR: AES-GCM and OpenCrypto work review
John-Mark Gurney j...@funkthat.com writes: Over the last few months, I've been working on a project to add support for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is sponsored by The FreeBSD Foundation and Netgate. I plan on committing these patches early next week. If you need more time for review, please email me privately and I will make delay. Please remember to bump __FreeBSD_version. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Looks fixed now, but what confused me is that r273919 modifies etc/rc.d/geli. I've not configured GELI neither in head VM nor stable/10 host. Yes, it breaks the cycle in the rcorder graph. Whether you use geli or not is irrelevant; the script still runs. *Noticed that r273919 should fix above by your reply, backed out Manfred's workaround [no other change] and rebooted, can't reproduce the mfsvar problem anymore! Yes, that was the idea. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Tomoaki AOKI junch...@dec.sakura.ne.jp writes: Dag-Erling Smørgrav d...@des.no writes: Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. [...] If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. For me, Manfred's workaround actually helped. It helped that particular issue, more or less by accident. It was not in any way a correct fix or even a correct workaround. In single user mode, actual /var (in root partition) appears as before. So there can be some mis-ordering within rc scripts. (Remounting of / is delayed? Check for /var too early?) Exactly right; the check for a writeable /var occurred before / was mounted r/w, so it mounted an mfs instead. Xin fixed this in r273919. For me, [unblocking /dev/random] takes nearly 2 minutes each boot after r273872. No specific rc.conf setting for it. That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: That means we're not getting enough entropy during early boot, or we're underestimating the amount of entropy we're getting. We added entropy harvesting to device_attach() about a year ago, which in most cases provides enough entropy to unblock /dev/random before we even run init(8). And I vaguely remember being promised that things like that would NEVER happen, even on systems with little or no entropy available during early startup (which describes quite nicely the embedded systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Ian Lepore i...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. How about you take a ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
O. Hartmann ohart...@zedat.fu-berlin.de writes: r273800 was the last (obviously) working on one box, r273872 seems to have the problem: Are you sure? If I understand Manfred correctly, r273905 was running fine for him. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: Two idea here: a) create a tunable security.pax.expert_mode, and create sysctls at boot time depending from expert mode b) just add CTLFLAG_SKIP and hide the sysctl from normal user The cost of an unused sysctl is about a hundred bytes of kernel memory. What is the cost of the code required to turn it on and off, keeping in mind that most of the contents of the struct sysctl_oid must be present anyway so you can fill in the malloc()ed node? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl What exactly is the purpose of PAX LOG? Have you considered using ktrace instead? PAX: blacklist clang and related binaries from PIE support Why? Performance, or do they actually break? PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable don't support as in you have tested them and confirmed that they break in some way? Could you post your test methodology so people can replicate the failures and look into fixing them? PAX ASLR: Use a full kernel config for LATT-ASLR What is the difference between LATT-ASLR and OP-ASLR, and why not just include GENERIC? You know about nooptions, right? Revert PAX: blacklist clang and related binaries from PIE support Revert Revert PAX: blacklist clang and related binaries from PIE support Hmm... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable
Oliver Pinter oliver.p...@gmail.com writes: pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
