Re: Frequent disk I/O stalls while building (poudriere), processes in "zfs tear" state

[Dewayne Geraghty]

On 16/04/2021 2:29 am, Felix Palmen wrote:
> After more experimentation, I finally found what's causing these
> problems for me on 13:
> 
> * Felix Palmen  [20210412 11:44]:
>> * Poudriere running on idprio 22 with 8 parallel build jobs
> 
> Running poudriere with normal priority works perfectly fine. Now, I've
> had poudriere running on idprio because there are several other services
> on that machine that shouldn't be slowed down by running a heavy build
> and I still want to use all the CPU resources available for building.
> 
> Right now, I'm running a test with idprio 0 instead, which still seems
> to have the desired effect, and so far, I didn't have any of these
> stalls. If this persists, the problem is solved for me!
> 
> I'd still be curious about what might be the cause, and, what this state
> "zfs tear" actually means. But that's kind of an "academic interest"
> now.
> 

Most likely your other processes are pre-empting your build, which is
what you want :).

Use /usr/bin/top to see the priority of the processes (ie under the  PRI
column).  Using an idprio 22, means (on my 12.2Stable) a PRI of 146.  If
your kern.sched.preempt_thresh is using the default (of 80) then
processes with a PRI of <80 will preempt (for IO).

Even with an idprio 0, the PRI is 124. So I suspect that was more a
matter of timing (ie good luck).

You could increase your pre-emption threshold for the duration of the
build, to include your nice value. But... (not really a good idea).
Better if you run your build using nice (PRI of 76) which should avoid
the stalls, but should also influence your more important services.

Re zfs - sorry, I'm peculiar and don't use it ;)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: stable/13, vm page counts do not add up

[Dewayne Geraghty]

On 8/04/2021 2:59 pm, Helge Oldach wrote:
> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:
>>
>> I regularly see that the top's memory line does not add up (and by a 
>> lot).
>> That can be seen with vm.stats as well.
>>
>> For example:
>> $ sysctl vm.stats | fgrep count
>> vm.stats.vm.v_cache_count: 0
>> vm.stats.vm.v_user_wire_count: 3231
>> vm.stats.vm.v_laundry_count: 262058
>> vm.stats.vm.v_inactive_count: 3054178
>> vm.stats.vm.v_active_count: 621131
>> vm.stats.vm.v_wire_count: 1871176
>> vm.stats.vm.v_free_count: 18
>> vm.stats.vm.v_page_count: 8134982
>>
>> $ bc
> 18 + 1871176 + 621131 + 3054178 + 262058
>> 5996320
> 8134982 - 5996320
>> 2138662
>>
>> As you can see, it's not a small number of pages either.
>> Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on 
>> this
>> system.
>>
>> This is 47c00a9835926e96, 13.0-STABLE amd64.
>> I do not think that I saw anything like that when I used (much) older 
>> FreeBSD.
> 
> That sounds like PR 234559 which has an explanation.
> 
> Kind regards
> Helge
> 

Thanks Helge, I appreciate the pointer to understand from Mark J. in
2019 that:
"Basically, we started lazily dequeuing wired pages to avoid the page
queue synchronization cost incurred by frequent wirings.  The result is
that wired pages may temporarily be counted as active/inactive/laundry
despite not being reclaimable.  Maintaining the previous behaviour wrt
statistics would introduce synchronization overhead that we've been
trying to avoid" (#1)

A minor and known counting error to avoid sync'ing overhead is fine.

Ref #1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234559
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: stable/13, vm page counts do not add up

[Dewayne Geraghty]

On 8/04/2021 6:56 am, Mark Johnston wrote:
> On Wed, Apr 07, 2021 at 11:22:41PM +0300, Andriy Gapon wrote:
>> On 07/04/2021 22:54, Mark Johnston wrote:
>>> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote:

 I regularly see that the top's memory line does not add up (and by a lot).
 That can be seen with vm.stats as well.

 For example:
 $ sysctl vm.stats | fgrep count
 vm.stats.vm.v_cache_count: 0
 vm.stats.vm.v_user_wire_count: 3231
 vm.stats.vm.v_laundry_count: 262058
 vm.stats.vm.v_inactive_count: 3054178
 vm.stats.vm.v_active_count: 621131
 vm.stats.vm.v_wire_count: 1871176
 vm.stats.vm.v_free_count: 18
 vm.stats.vm.v_page_count: 8134982

 $ bc
>>> 18 + 1871176 + 621131 + 3054178 + 262058
 5996320
>>> 8134982 - 5996320
 2138662

 As you can see, it's not a small number of pages either.
 Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on 
 this
 system.

 This is 47c00a9835926e96, 13.0-STABLE amd64.
 I do not think that I saw anything like that when I used (much) older 
 FreeBSD.

For reference, I think that a smaller error has been around for awhile.
 On a UFS only system,
FreeBSD 12.2-STABLE #0 r369523M: Sat Mar 27 00:27:03 AEDT 2021
I have:

# sysctl vm.stats | fgrep count; top -b
vm.stats.vm.v_cache_count: 0
vm.stats.vm.v_user_wire_count: 0
vm.stats.vm.v_laundry_count: 0
vm.stats.vm.v_inactive_count: 423959
vm.stats.vm.v_active_count: 82623
vm.stats.vm.v_wire_count: 256273
vm.stats.vm.v_free_count: 5457329
vm.stats.vm.v_page_count: 6112118
last pid: 83881;  load averages:  0.07,  0.09,  0.06  up 0+07:31:44
12:59:37
90 processes:  1 running, 89 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.9% idle
Mem: 323M Active, 1656M Inact, 1001M Wired, 585M Buf, 21G Free
Swap: 24G Total, 24G Free

# bc
423959+82623+256273+5457329
6220184
6112118 - 6220184
-108066
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possibly silly question regarding freebsd-update

[Dewayne Geraghty]

On 31/03/2021 12:35 am, tech-lists wrote:
> Hi,
> 
> Recently there was
> https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html
> about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted.
> 
> What I'm unsure about is the openssl version.
> Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd  22 Sep 2020
> 
> Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd
> 25 Mar 2021
> 
> shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well?
> 
> thanks,

I think you'll find your answer by comparing the changes between
release 12.2-p5 and stable 12.2 below:

https://cgit.freebsd.org/src/commit/?h=releng/12.2=af61348d61f51a88b438d41c3c91b56b2b65ed9b

with

https://cgit.freebsd.org/src/commit/?h=stable/12=18d07050e60ecc738556f0de56e34817303371a4

stable 12.2 has the full upgrade to openssl 1.1.1k, while release
12.2-p5 addresses the specific vulnerability(s).
Regards, Dewayne
PS cgit I'm told is the source of truth :)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Filesystem operations slower in 13.0 than 12.2

[Dewayne Geraghty]

Thanks Helge, there is a 10% increase in involuntary context switching
which suggests that other things were occurring on the testing platform
 during the 13.0B4 run or 13 has adversely changed?  (And I'd discount
the latter due to the voluntary CS being similar across runs)

I appreciate you taking the time to perform difference tests, but think
that your tests need to be run under identical conditions :)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: where to upgrade 12-stable now, svn still, or git?

[Dewayne Geraghty]

On 13/02/2021 1:11 pm, Mark Millard via freebsd-stable wrote:
>> As subject, where to get sources for 12-stable upgrade now? Is it still
>> svn or is it git?
> 
> Probably your choice. But one thing that could
> bias towards svn is that the svn information
> spans identifying both the svn and the git
> material but the git commit does not identify
> the svn material. For example, via:
> 
> https://svnweb.freebsd.org/base/stable/12/lib/?sortby=rev=down=log
> 
> is the following . . .
... [ Quite lenghty ref earlier email]
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
Thanks for raising the thread.  I'm in a similar boat.  Though, prior to
an update, we'd review the changes via the mailing lists.

The main list we used was:
https://lists.freebsd.org/pipermail/svn-src-stable-12/
but that appears dead.  Normally we'd update fortnightly or trigger an
update when there was an incremental patch update to "release" as
advised via:
https://lists.freebsd.org/pipermail/svn-src-release/
suspect also dead.

Suggestion  - final entry in dead lists to provide a pointer to its git
equivalent?

I suspect that
https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-January/thread.html
is the stable-12 equivalent but are incremental patch releases also
available here?

As a change management task, I would hope that a mapping between svnlite
and git would've become available for FreeBSD users, similar to the cvs
to svnlite migration.  I guess we need to create a test machine to
figure out the commands we need for git to replace what we use in the
scripts (mainly "update -r "{$DATE}", diff and log along with the
incantation to create a git repository).

I wish that I could articulate the reason to management that FreeBSD is
making the move from svn to git?

Is there a timeline when svn for stable-12 /usr/src disappears?

(I'm dreading a ports move to a git paradigm...)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 13.0-BETA1: ipfw regression?

[Dewayne Geraghty]

Stefan, Would you check that you have net.inet.tcp.always_keepalive=1,
and perhaps that net.inet.tcp.keepidle and net.inet.tcp.keepintvl are
reasonable to ensure that the expected keep alives are running.  I don't
have a FreeBSD 13 to view the defaults, but Helge might be right that
"it" is already fixed :)
Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Is git/svn in sync with FreeBSD12.2Stable

[Dewayne Geraghty]

I'm using
https://cgit.freebsd.org/src/log/?h=stable%2F12
to monitor changes to FreeBSD 12.2Stable, as I used to use
https://lists.freebsd.org/pipermail/svn-src-stable-12/2020-December/

The git site has substantially more changes than
# svnlite update /usr/src
Updating '/usr/src':
U/usr/src/tests/sys/sys/bitstring_test.c
U/usr/src/sys/dev/superio/superio.c
U/usr/src/sys/dev/ice/ice_common.h
U/usr/src/sys/dev/qat/qat_ae.c
U/usr/src/sys/dev/ntb/ntb_hw/ntb_hw_intel.c
U/usr/src/sys/amd64/amd64/support.S
U/usr/src/sys/i386/i386/support.s
U/usr/src/sys/modules/em/Makefile
U/usr/src/sys/netinet/sctp_input.c
U/usr/src/sys/conf/kern.mk
U/usr/src/sys/vm/uma_core.c
U/usr/src/libexec/rtld-elf/i386/reloc.c
U/usr/src/libexec/tftpd/tftp-io.c
U/usr/src/libexec/tftpd/tftp-transfer.c
U/usr/src/lib/msun/Makefile
U/usr/src/sbin/hastd/hastd.c
U/usr/src/share/mk/bsd.sys.mk
U/usr/src/usr.bin/locate/locate/locate.1
U   /usr/src

The above updated /usr/src from:
Last Changed Author: rew
Last Changed Rev: 368733
Last Changed Date: 2020-12-18 06:49:17 +1100 (Fri, 18 Dec 2020)

Am I misreading the git log or is sync'ing not occurring?

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Has geli broken when using authentication (hmac/sha256)?

[Dewayne Geraghty]

Using FreeBSD 12.2S r367125M, to
# geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
fails during newfs,
# newfs -O2 -U ${D}s1a.eli
newfs: can't read old UFS1 superblock: read error from block device:
Invalid argument

Using geli with encryption only, works as usual. But using hmac/sha256
fails when used with "-e null" or in combination with a cipher.

Using encryption only, everything is normal, ie newfs ok, the filesystem
mounts and is accessible.

Could someone verify if something is broken?  I've included my test case
below:

-- 
Reproducible with:

D=/dev/md0
# Cleanup previous runs
umount /mnt/A
geli detach ${D}s1a || true
mdconfig -du 0 || TRUE
rm /tmp/test || true

truncate -s 64m /tmp/test
mdconfig -t vnode -f /tmp/test

gpart create -s MBR ${D}
gpart add -a 4k -s 14m -t freebsd $D
gpart add -a 4k -s 10m -t freebsd $D
gpart add -a 4k -s 10m -t freebsd $D
gpart create -s bsd ${D}s1
gpart create -s bsd ${D}s2

gpart add -a 4k   -s 10m -t freebsd-ufs ${D}s1

openssl rand -hex -out /tmp/key 32
geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
geli attach -p -k /tmp/key ${D}s1a

newfs -O2 -U ${D}s1a.eli
/dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 2.25MB, 72 blks, 384 inodes.
with soft updates
newfs: can't read old UFS1 superblock: read error from block device:
Invalid argument

However using UFS1, newfs succeeds but the mount fails.

newfs -O1 -U ${D}s1a.eli
/dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 2.25MB, 72 blks, 512 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
 64, 4672, 9280, 13888
# mount -v /dev/md0s1a.eli /mnt/A
mount: /dev/md0s1a.eli: Invalid argument


The only change that may be related is:

# svnlite log -l 4  /usr/src/tests/sys/geom/class/eli

r363486 | asomers | 2020-07-25 04:19:25 +1000 (Sat, 25 Jul 2020) | 13 lines

MFC r363014:

geli: enable direct dispatch

geli does all of its crypto operations in a separate thread pool, so
g_eli_start, g_eli_read_done, and g_eli_write_done don't actually do very
much work. Enabling direct dispatch eliminates the g_up/g_down bottlenecks,
doubling IOPs on my system. This change does not affect the thread pool.

Reviewed by:markj
Sponsored by:   Axcient
Differential Revision:  https://reviews.freebsd.org/D25587

Cheers, Dewayne

-- 
*** NOTICE This email and any attachments may contain legally privileged
or confidential information and may be protected by copyright. You must
not use or disclose them other than for the purposes for which they were
supplied. The privilege or confidentiality attached to this message and
attachments is not waived by reason of mistaken delivery to you. If you
are not the intended recipient, you must not use, disclose, retain,
forward or reproduce this message or any attachments. If you receive
this message in error please notify the sender by return email or
telephone and destroy and delete all copies. ***
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Unusual display from sysctl on FBSD12.2S

[Dewayne Geraghty]

On 26/09/2020 12:11 am, Andrey V. Elsukov wrote:
> On 25.09.2020 09:27, Dewayne Geraghty wrote:
>> sysctl -a or sysctl vm displays on syserr,
>> sysctl: S_vmtotal 48 != 88
>>
>> on FreeBSD 12.2-STABLE #0 r365645M.  Are others experiencing this?
>>
>> It has been this way for a few months.
> Hi,
> 
> This means that your sysctl(8) binary is out of sync with your kernel.
> You need rebuild and reinstall it or the whole world.
> 

Thanks Audrey, appreciate the input.  I'll need to investigate further,
as I seem to be alone with this anomaly.  I rebuilt and reinstalled from
the 13th Sept source:

~# lh /boot/kernel/kernel /sbin/sysctl /lib/libc.so.7 ; date;  uptime;
sysctl vm>>/dev/null
-r-xr-xr-x  1 root  wheel15M 26 Sep 17:04 /boot/kernel/kernel*
-r--r--r--  1 root  wheel   1.9M 26 Sep 17:04 /lib/libc.so.7
-r-xr-xr-x  1 root  wheel23K 26 Sep 17:05 /sbin/sysctl*
Sat 26 Sep 2020 17:48:42 AEST
 5:48PM  up 36 mins, 1 user, load averages: 0.02, 0.06, 0.08
sysctl: S_vmtotal 48 != 88

FreeBSD hathor 12.2-STABLE FreeBSD 12.2-STABLE #0 r365645M: Sun Sep 13
04:00:22 AEST 2020
root@hathor:/usr/obj/prod/120109/D/K8/smallblocks/src/amd64.amd64/sys/hqdev-amd64-smp-vga
amd64 1202500 1202500

>From /usr/src/sbin/sysctl/sysctl.c:
   if (l2 != sizeof(*v)) {
warnx("S_vmtotal %zu != %zu", l2, sizeof(*v));
return (1);
}

Kind regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Unusual display from sysctl on FBSD12.2S

[Dewayne Geraghty]

sysctl -a or sysctl vm displays on syserr,
sysctl: S_vmtotal 48 != 88

on FreeBSD 12.2-STABLE #0 r365645M.  Are others experiencing this?

It has been this way for a few months.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

init_exec precedence, before or after init_script?

[Dewayne Geraghty]

A recent change to init, has introduced the welcome init_exec kenv.
Unfortunately "man init" indicates ambiguity as both: init_script and
init_exec are run as "the very first action".  So that needs a change.

Due to this ambiguity I referred to the source, and init_exec is
performed first.  As init_script has been around for awhile, may I
suggest that it be first and init_exec then take over the PID 1 position?

It also suits my use case, where I have a script that does some file
system work before transferring to init_exec, something I look forward
to taking advantage of (rather than my current init hack) ;)

Regards, Dewayne
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: The spkr driver

[Dewayne Geraghty]

Appreciate the notice Warner.  :)

Yes, I use it on various devices:
- as a clock signal to indicate the time, different pitch each 1/4 &
hour (aka a chiming clock, very useful when busy)
- advice when a box has completed booting
- advice when snort (& others) thinks there's a problem
using different duration and pitch.  I'm Pavlovian trained.

audio/beep and audio/yell are good friends that need their benefactor Mr
Speaker to remain alive, please.  ;)

I'm rarely current but always stable (12.1), happy to test (on: Haswell,
Nehalem, Nehemiah (32bit))
Regards.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Upgrading to 12.1S 362003 - a few issues

[Dewayne Geraghty]

>> I've placed the ktrace (sq3.kt.xz) and LD_DEBUG output (sq.deb.xz) at
>> http://www.heuristicsystems.com/squid4K
> No need, the problem occurs somewhere in user code.  Try to build the
> binary with debug symbols and look into the coredump with gdb.
> 
>>
>> Pity about ldd, but I appreciate the complexity & the effort.  I'm also
>> comforted that it isn't an error, rather the evolution of ldd :)
> ldd should be fixed after https://reviews.freebsd.org/D25257 is committed.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Thank-you Konstantin, I appreciate your advice.  Though that will be
difficult without a functioning pkg so I'll wait a while to see if
others have a problem.

It is however, very odd that a "fat" squid et al worked for months prior
to the FreeBSD update (the production jail is very rarely changed ie
years, except for FreeBSD updates).  I'll see if there is something in
the libc logs that shed some light.

Kind regards, Dewayne.
PS I noticed segmentation faults in bare metal i386 hardware a few
months ago, but wasn't able to find the problem. Guess not many build
i386 systems on amd64...
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Upgrading to 12.1S 362003 - a few issues

[Dewayne Geraghty]

Hi Konstantin,
I did try ktrace/kdump but kdump complained of "data too short".  Using
your suggestion about LD_DEBUG nearly caused me to fall off my chair.  I
think this is most relevant:

# setenv LD_DEBUG 1
# ktrace -f /tmp/sq3.kt /usr/local/sbin/squid start
/libexec/ld-elf.so.1 is initialized, base address = 0x8aded000
RTLD dynamic = 0x8ae0f6c0
RTLD pltgot  = 0
initializing thread locks
_rtld_thread_init: done
processing main program's program header
note osrel 1201517
note fctl0 0
note crt_no_init
AT_EXECPATH 0xdfe0 /usr/bin/ktrace
obj_main path /usr/bin/ktrace
Filling in DT_DEBUG entry
Ignoring d_tag 1879048186 = 0x6ffa
/usr/bin/ktrace valid_hash_sysv 1 valid_hash_gnu 0 dynsymcount 30
lm_init("(null)")
loading LD_PRELOAD libraries
loading needed objects
 Searching for "libc.so.7"
search_library_pathfds('libc.so.7', '(null)', fdp)
lm_find("/usr/bin/ktrace", "/lib")
lmp_find("/usr/bin/ktrace")
lmp_find("$DEFAULT$")
  Trying "/lib/libc.so.7"
  Opened "/lib/libc.so.7", fd 3
loading "/lib/libc.so.7"
Ignoring d_tag 1879048186 = 0x6ffa
/lib/libc.so.7 valid_hash_sysv 1 valid_hash_gnu 1 dynsymcount 3126
  0x6d20f000 .. 0x6d3eafff: /lib/libc.so.7
checking for required versions
initializing initial thread local storage offsets
relocating "/usr/bin/ktrace"
reloc_jmpslot: *0x4b177c04 = 0x6d39bac0
reloc_jmpslot: *0x4b177c08 = 0x6d3b6480
... [ Lots of these ]
reloc_jmpslot: *0x9d4859fc = 0x9d46e560
reloc_jmpslot: *0x9d485a00 = 0x9d47a428
reloc_jmpslot: *0x9d485a04 = 0x9d47a448
relocating "/usr/local/lib/heimdal/libasn1.so.8"
relocating "/usr/local/lib/heimdal/libwind.so.0"
relocating "/usr/local/lib/heimdal/libheimbase.so.1"
relocating "/usr/local/lib/heimdal/libhx509.so.5"
relocating "/usr/local/lib/heimdal/libhcrypto.so.4"
relocating "/usr/local/lib/heimdal/libheimsqlite.so.0"
relocating "/usr/local/lib/heimdal/libcom_err.so.1"
relocating "/usr/local/lib/heimdal/libroken.so.18"
relocating "/usr/local/lib/libintl.so.8"
relocating "/usr/local/lib/heimdal/libheimntlm.so.0"
doing copy relocations
initializing initial thread local storage
initializing key program variables
"__progname": *0x73be38b8 <-- 0xdd44
"environ": *0x73cbbc08 <-- 0xfffc69cc
"__elf_aux_vector": *0x9d4a6a5c <-- 0xfffc6a4c
resolving ifuncs
reloc_jmpslot: *0x9d484d88 = 0x9d352cc0
reloc_jmpslot: *0x9d484d8c = 0x9d352c70
reloc_jmpslot: *0x9cb16e04 = 0x9d352c70
reloc_jmpslot: *0x9cb16e0c = 0x9d352cc0
calling init function for /lib/libc.so.7 at 0x9d47c440
calling init function for /lib/libc.so.7 at 0x9d40fc20
calling init function for /lib/libc.so.7 at 0x9d3f0f40
calling init function for /lib/libthr.so.3 at 0x9cb15210
calling init function for /lib/libthr.so.3 at 0x9cb10cb0
_rtld_thread_init: done
calling init function for /lib/libgcc_s.so.1 at 0x9bfad540
calling init function for /lib/libgcc_s.so.1 at 0x9bfa3de0
calling init function for /lib/libcxxrt.so.1 at 0x9b698480
calling init function for /usr/lib/libc++.so.1 at 0x9ab43d90
calling init function for /usr/lib/libc++.so.1 at 0x9aae3e40
calling init function for /lib/libcrypt.so.5 at 0x965d3210
calling init function for /usr/local/lib/libcrypto.so.11 at 0x96e9f420
calling init function for /usr/local/lib/heimdal/libroken.so.18 at
0xa32b6f60
calling init function for /usr/local/lib/libintl.so.8 at 0xa23cb104
calling init function for /usr/local/lib/heimdal/libheimbase.so.1 at
0x9ed15de0
calling init function for /usr/local/lib/heimdal/libcom_err.so.1 at
0x9fec3768
calling init function for /usr/local/lib/heimdal/libasn1.so.8 at 0x9e23f054
calling init function for /usr/local/lib/heimdal/libhcrypto.so.4 at
0x9fb5641c
calling init function for /usr/local/lib/heimdal/libheimsqlite.so.0 at
0xa1b9603c
calling init function for /usr/local/lib/heimdal/libwind.so.0 at 0x9f77a990
calling init function for /usr/local/lib/heimdal/libhx509.so.5 at 0xa0c4e3b4
calling init function for /usr/local/lib/heimdal/libkrb5.so.26 at 0x99527188
calling init function for /usr/local/lib/heimdal/libheimntlm.so.0 at
0xa498c814
calling init function for /usr/local/lib/heimdal/libgssapi.so.3 at
0x9a45bfd0
calling init function for /usr/local/lib/libpcre.so.1 at 0x97550ca8
calling init function for /usr/local/lib/libpcreposix.so.0 at 0x9728e518
calling init function for /lib/libm.so.5 at 0x97139f10
calling init function for /usr/local/lib/libssl.so.11 at 0x98579078
calling init function for /usr/lib/libregex.so.1 at 0x95e8f0a0
calling init function for /usr/lib/librt.so.1 at 0x953ca240
loading filtees
enforcing main obj relro
transferring control to program entry point = 0x73757360
"atexit" in "squid" ==> 0x9d457ac0 in "libc.so.7"
reloc_jmpslot: *0x73be32b4 = 0x9d457ac0
"_ZSt13set_terminatePFvvE" in "squid" ==> 0x9b697a30 in "libcxxrt.so.1"
reloc_jmpslot: *0x73be3794 = 0x9b697a30
"strlen" in "squid" ==> 0x9d4750b0 in "libc.so.7"
reloc_jmpslot: *0x73be3108 = 0x9d4750b0
"malloc" in "squid" ==> 0x9d3e6620 in "libc.so.7"
reloc_jmpslot: *0x73be3820 = 0x9d3e6620
"memcpy" in "squid" ==> 0x9d47aa20 in "libc.so.7"

Upgrading to 12.1S 362003 - a few issues

[Dewayne Geraghty]

After upgrading to 12.1Stable as of June 11:
1) squid - fails with segmentation fault, ldd "Cannot load PIE binary"
2) gcc9 - suffers a cc1 internal compiler error
3) pkg-static - issues "failed" messages, unable to package or install

Environment Xeon E3, ufs2 only, previously running FreeBSD 12.1 dated
1st May (from kernel.old).
Prior to the upgrade all ports were rebuilt without issue, but NOT
installed as they were a fall-back, in the event that clang 10 caused
issues (the concern).  There are multiple jails on this system, both
amd64 and i386 - some for building, testing and production use.  One of
the production i386 jails runs squid, unchanged since Sept 2019.

/etc/src.conf contains
WITH_PIE=YES
WITH_BIND_NOW=YES

Most of our 1400+ ports are built and run with relro, now, pie and where
possible with noexecstack &/or no-common.  These functioned in an ASLR
environment.  (ASLR is only disabled during builds (gcc9 complains), or
when there's a problem, now).

Note: NONE of the ports were rebuilt after the upgrade. However as part
of resolution, beep and squid were rebuilt.

=== Sequence of thigns ===

Upgrade performed.  System rebooted without incident to
FreeBSD 12.1-STABLE #0 r362003M: Thu Jun 11 23:07:00 AEST 2020  i386
hqdev-amd64-smp-vga 1201517 1201517
but some port/application failures:

Problem 1
-

i386 jail demonstrated:

# /usr/local/etc/rc.d/squid start
Starting squid.
Segmentation fault

# ldd /usr/local/sbin/squid
/usr/local/sbin/squid:
ldd: /usr/local/sbin/squid: Cannot load PIE binary /usr/local/sbin/squid
as DSO
/usr/local/sbin/squid: exit status 1

Lets check some relevant sysctls:
~# sysctl kern.elf64
kern.elf64.aslr.stack_gap: 0
kern.elf64.aslr.honor_sbrk: 1
kern.elf64.aslr.pie_enable: 0
kern.elf64.aslr.enable: 0
kern.elf64.pie_base: 16912384
kern.elf64.nxstack: 0
kern.elf64.fallback_brand: -1

~# sysctl kern.elf32
kern.elf32.aslr.stack_gap: 0
kern.elf32.aslr.honor_sbrk: 1
kern.elf32.aslr.pie_enable: 0
kern.elf32.aslr.enable: 0
kern.elf32.pie_base: 16781312
kern.elf32.read_exec: 0
kern.elf32.nxstack: 0
kern.elf32.fallback_brand: -1

Perhaps this may be helpful to the reader?
# readelf -d /usr/local/sbin/squid

Dynamic section at offset 0x5c contains 39 entries:
  TagType  Name/Value
 0x0001 NEEDED   Shared library: [librt.so.1]
 0x0001 NEEDED   Shared library: [libcrypt.so.5]
 0x0001 NEEDED   Shared library: [libregex.so.1]
 0x0001 NEEDED   Shared library: [libcrypto.so.11]
 0x0001 NEEDED   Shared library: [libssl.so.11]
 0x0001 NEEDED   Shared library: [libm.so.5]
 0x0001 NEEDED   Shared library: [libpcreposix.so.0]
 0x0001 NEEDED   Shared library: [libpcre.so.1]
 0x0001 NEEDED   Shared library: [libkrb5.so.26]
 0x0001 NEEDED   Shared library: [libgssapi.so.3]
 0x0001 NEEDED   Shared library: [libc++.so.1]
 0x0001 NEEDED   Shared library: [libcxxrt.so.1]
 0x0001 NEEDED   Shared library: [libgcc_s.so.1]
 0x0001 NEEDED   Shared library: [libthr.so.3]
 0x0001 NEEDED   Shared library: [libc.so.7]
 0x001d RUNPATH  Library runpath:
[/usr/local/lib/heimdal:/usr/lib:/usr/local/lib]
 0x000c INIT 0xfe0d8
 0x000d FINI 0x45e0b0
 0x0019 INIT_ARRAY
 0x001b INIT_ARRAYSZ 292 (bytes)
 0x0004 HASH 0x19c
 0x0005 STRTAB   0x4a520
 0x0006 SYMTAB   0x155c0
 0x000a STRSZ580827 (bytes)
 0x000b SYMENT   16 (bytes)
 0x0015 DEBUG0x0
 0x0003 PLTGOT   0x5e0c94
 0x0002 PLTRELSZ 4432 (bytes)
 0x0014 PLTREL   REL
 0x0017 JMPREL   0xfcf88
 0x0011 REL  0xded48
 0x0012 RELSZ123456 (bytes)
 0x0013 RELENT   8 (bytes)
 0x6ffb FLAGS_1  unknown (0x800)
 0x6ffe VERNEED  0xdebe8
 0x6fff VERNEEDNUM   9
 0x6ff0 VERSYM   0xd81fc
 0x6ffa RELCOUNT 13575
 0x NULL 0x0


Finding the "Cannont load PIE" string in "/usr/src/libexec/rtld-elf/rtld.c"
So commented out the code:
if (obj->z_pie) {
_rtld_error("Cannot load PIE binary %s as DSO", obj->path);
goto errp;
just to get going...

# cd /usr/src/libexec/rtld-elf
# make -DUSE_K8 clean && make -DUSE_K8 && make -DUSE_K8 install
...
cc -O2 -pipe -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UDEBUG
-DUSB_HAVE_DISABLE_ENUM -O2 -fno-math-errno -fomit-frame-pointer
-Wno-error=unused-command-line-argument -Wl,--hash-style=sysv
-fno-common -march=haswell -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding
-I/smallblocks/src/lib/csu/common
-I/smallblocks/src/libexec/rtld-elf/amd64

Re: ntp problems stratum 2 to 14?

[Dewayne Geraghty]

> The interrupted system calls (EINTR returned from select()) are normal.
> Notice that each time it happens, it's associated with a SIGALARM being
> delivered to ntpd.  Ntpd uses SIGALARM at 1hz to periodically get
> control and decide whether it's time to poll peers and do other
> periodic work.
>
> You say 10.0.7.6 syncs with some atomic clocks, but in your initial
> posting it was sync'd to its own LOCL clock at stratum 14, which is why
> the ntpd you were asking about refused to sync to it and also fell back
> to its own LOCL clock.  Eventually 10.0.7.6 sync'd to 203.35.83.242,
> then the system you were asking about sync'd to 10.0.7.6.
>
> -- Ian
>
>
>
Thankyou for your insight; comforting to know that its normal/expected, so
I don't need to follow that down.

Yes, I probably caught 10.0.7.6  restarting ntp as I was trying to
determine if there was some new incompatability or I changed some firewall
rule, so I may have inadvertently blocked it.  I apologise for complicating
the original situation/post.  Typically 10.0.7.6 is rebooted when the UPS
needs new batteries, acting as firewall and time server.

-- 
*** *NOTICE *This email and any attachments may contain legally privileged
or confidential information and may be protected by copyright. You must not
use or disclose them other than for the purposes for which they were
supplied. The privilege or confidentiality attached to this message and
attachments is not waived by reason of mistaken delivery to you. If you are
not the intended recipient, you must not use, disclose, retain, forward or
reproduce this message or any attachments. If you receive this message in
error please notify the sender by return email or telephone, and destroy
and delete all copies. ***
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ntp problems stratum 2 to 14?

[Dewayne Geraghty]

Ian,  Good points.  I did remove the fudge and 127.127.1.1 lines from the
config with the same result as below.  Interestingly the clock at 10.0.7.6
isn't really unreliable, as its been my time source since 2005, and serves
clients, so it is pretty ok. Without a local clock, named fails (its linked
with kerberos).  Yes I'd never seen my clock server become st 14, which
prompted me to seek help. I haven't repeated that scenario, but I
continuously get "interrupted system call" and I haven't been able to sync
while running debug or ktrace - so I dont have "what good looks like".

Thanks Peter. I've rebuilt net/ntpd in various ways including all
defaults.  Rebuilt the kernel (& world), to the latest 12 stable.
Reset almost all sysctl's (I change 91 of them).  I keep getting
interrupted system call at 1 sec intervals, which I suspect is a problem

For the reader: a stratum 2 clocks 10.0.7.6 syncs with some atomic clocks
within city; a server 10.0.7.91 running ntpd 4.2.8p14 on FreeBSD 12.1
r358565M irregularly and usually wont sync, and experiences "interrupted
system calls".

The jump to stratum 14 was a surprise, but not repeatable.  Sometimes the
ntpd port starts and uses the next hop time server, but usually within 20
minutes returns to LOCL though more often goes straight to LOCL.  During
ktrace's I've observed:

 66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
 66894 ntpd GIO   fd 1 wrote 46 bytes
   "select() returned -1: Interrupted system call
...
   "poll_update: at 1 10.0.7.6 poll 4 burst 0 retry 2 head 14 early 2
next 16
   "
 66894 ntpd RET   write 74/0x4a
 66894 ntpd CALL  select(0x19,0x7fffde50,0,0,0)
 66894 ntpd RET   select -1 errno 4 Interrupted system call
 66894 ntpd PSIG  SIGALRM caught handler=0x80072f600 mask=0x0
code=SI_KERNEL
 66894 ntpd CALL  sigprocmask(SIG_SETMASK,0x7fffd7a4,0)
 66894 ntpd RET   sigprocmask 0
 66894 ntpd CALL  sigreturn(0x7fffd3d0)
 66894 ntpd RET   sigreturn JUSTRETURN
 66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
 66894 ntpd GIO   fd 1 wrote 46 bytes
   "select() returned -1: Interrupted system call
...
   "select() returned -1: Interrupted system call
   "
 66894 ntpd RET   write 46/0x2e
 66894 ntpd CALL  select(0x19,0x7fffde50,0,0,0)
 66894 ntpd RET   select -1 errno 4 Interrupted system call
 66894 ntpd PSIG  SIGALRM caught handler=0x80072f600 mask=0x0
code=SI_KERNEL
 66894 ntpd CALL  sigprocmask(SIG_SETMASK,0x7fffd7a4,0)
 66894 ntpd RET   sigprocmask 0
 66894 ntpd CALL  sigreturn(0x7fffd3d0)
 66894 ntpd RET   sigreturn JUSTRETURN
 66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
 66894 ntpd GIO   fd 1 wrote 46 bytes
   "select() returned -1: Interrupted system call
but I have no idea whether or not these interrupted system calls are normal
or not.

and with debug (-D5) this is what I see

 5 Mar 18:26:50 ntpd[86274]: select(): nfound=-1, error: Interrupted system
call
alarming: normal
 5 Mar 18:26:51 ntpd[86274]: select(): nfound=-1, error: Interrupted system
call
poll_update: at 17 10.0.7.6 poll 4 burst 0 retry 0 head 0 early 2 next 16
sendpkt(21, dst=10.0.7.6, src=10.0.7.91, ttl=0, len=72)
peer_xmit: at 17 10.0.7.91->10.0.7.6 mode 3 keyid 232f len 72 index 0
read_network_packet: fd=21 length 72 from 10.0.7.6
fetch_timestamp: system bintime network time stamp: 1583393211.408612992
restrictions: looking up 10.0.7.6
match_restrict4_addr: Checking 127.0.0.1, port 123 ... doesn't match:
ippeerlimit -4
match_restrict4_addr: Checking 127.0.0.1, port 123 ... doesn't match:
ippeerlimit -1
match_restrict4_addr: Checking 10.0.7.91, port 123 ... doesn't match:
ippeerlimit -4
match_restrict4_addr: Checking 10.0.7.6, port 123 ... MATCH: ippeerlimit -1
receive: at 17 10.0.7.91<-10.0.7.6 ippeerlimit -1 mode 4 iflags
up,broadcast,multicast restrict nomodify,nopeer,noquery,notrap org
0xe20b283b.687ad7f6 xmt 0xe20b2838.2001aa5b
MRU: interval 16 headway 8 limit 64
receive: at 17 10.0.7.91<-10.0.7.6 mode 4/server:AM_PROCPKT keyid 232f
len 72 auth 1 org 0xe20b283b.687ad7f6 xmt 0xe20b2838.2001aa5b MAC
receive: MATCH_ASSOC dispatch: mode 4/server:AM_PROCPKT
poll_update: at 17 10.0.7.6 poll 4 burst 0 retry 0 head 14 early 2 next 16
clock_filter: n 2 off -3.283397 del 0.000382 dsp 3.937561 jit 0.000551
alarming: normal
 5 Mar 18:26:52 ntpd[86274]: select(): nfound=-1, error: Interrupted system
call
alarming: normal
 5 Mar 18:26:53 ntpd[86274]: select(): nfound=-1, error: Interrupted system
call
alarming: normal

I have rebuild with ntp-4.2.8p14 and with no additional compile rules and
the port's defaults. I keep getting

 6 Mar 07:05:16 ntpd[98682]: select(): nfound=-1, error: Interrupted system
call
alarming: normal
 6 Mar 07:05:17 ntpd[98682]: select(): nfound=-1, error: Interrupted system
call
alarming: normal
 6 Mar 07:05:18 ntpd[98682]: select(): nfound=-1, error: Interrupted system
call
alarming: normal
 6 Mar 07:05:19 ntpd[98682]: 

Re: ntp problems stratum 2 to 14?

[Dewayne Geraghty]

On Thu, 27 Feb 2020 at 06:43, Peter Jeremy  wrote:

> On 2020-Feb-26 16:37:43 +1100, Dewayne Geraghty 
> wrote:
> >I usually run ntpd with both aslr and as user ntpd.  While testing I
> >noticed that my server with a direct network cable to my main time keeper,
> >jumped from the expected stratum 2 to 14 as follows (I record the date so
> I
> >can synch with the debug log, also below):
> >
> >vm.loadavg={ 0.09 0.10 0.18 }
> >
> >Wed 26 Feb 2020 15:16:38 AEDT
> > remote   refid  st t when poll reach   delay   offset
> > jitter
>
> >==
> > 10.0.7.6203.35.83.2422 u   44   64  3770.147  -227.12
> 33.560
> >*127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
> 0.000
>
> >26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
>
> Why is this bad?  You've specified that this is a valid clock source so
> ntpd is free to use it if it decides it is the best source of time.
>
> >server 127.127.1.1 minpoll 7 maxpoll 7
> >fudge  127.127.1.1 stratum 14
>
> Synchronizing to the local clock (ie using 127.127.1.x as a reference) is
> almost never correct.  What external (to NTP) source is being used to
> synchronize the local clock?
>
> >I'm also very surprised that the jitter on the server (under testing) is
> so
> >poor.  The internet facing time server is
> >*x.y.z.t   .ATOM.   1 u   73  5127   23.776   34.905  95.961
> >but its very old and not running aslr.
>
> The 23ms distance to the peer suggests that this is over the Internet.
> What
> sort of link do you have to the Internet and how heavily loaded is it?  The
> NTP protocol includes the assumption that the client-server path delay is
> symmetric - this is often untrue for SOHO connections.  And SOHO
> connections
> will often wind up saturated in one direction - which skews the apparent
> timestamps and shows up as high jitter values.
>
> > /usr/local/sbin/ntpd -c /etc/ntp.conf -g -g  -u ntpd --nofork
> ...
> >I get similar results with /usr/sbin/ntpd, I've been testing both and
> >happened to record details for the port ntpd.
>
> It's probably not relevant but it would be useful for you to say up front
> which ntpd you are having problems with and which version of the port you
> have installed.
>
> --
> Peter Jeremy
>

Hi Peter, I appreciate your thoughts. Yes, using LOCL is bad because it
should only be used when the stratum 2 machine is unavailable, and it isn't
(representative ping time average 0.15ms). The load is less than 10% on
both devices and both the internet and internal traffic is typically less
than 50Kb. :/

The use of LOCL clock was a fix as named failed if ntpd only used the
timeserver and it lost sync (due to some ipsec work another story), I
suspect kerberos had a part as it uses tkey-gssapi-keytab. I should
investigate why the use of LOCL clock makes things work, but ... its a
workaround and I'm ok with it.

I'm at my wits end, I've systematically changed one variable from the list,
and always the system clock reverts to LOCL within 20 minutes if not
immediately. This is FreeBSD 12.1-STABLE #0 r356046M: Tue Dec 24. I think
its time to try an earlier ntp to see if that helps (???) :(

The variables tested, one changed at a time:
- security.mac.ntpd.enabled
- kern.elf64.aslr.enable kern.elf64.aslr.stack_gap changed as a pair
- security.mac.portacl.rules
- run as root or ntpd
- use of proccontrol (which was changed with different combinations of
aslr, stack_gap
- all off and run as root
- and of course changes to the command line (-g or -G or -g -x)

I guess everyone else is using ntpd without a problem? (or not...)
Cheers, Dewayne
PS Apologies for delay in getting back, gmail placed your reply in the spam
folder :/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ntp problems stratum 2 to 14?

[Dewayne Geraghty]

I usually run ntpd with both aslr and as user ntpd.  While testing I
noticed that my server with a direct network cable to my main time keeper,
jumped from the expected stratum 2 to 14 as follows (I record the date so I
can synch with the debug log, also below):

vm.loadavg={ 0.09 0.10 0.18 }

Wed 26 Feb 2020 15:16:38 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
 10.0.7.6203.35.83.2422 u   44   64  3770.147  -227.12
 33.560
*127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
0.000
Wed 26 Feb 2020 15:18:46 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
 10.0.7.6LOCAL(1)14 u   42   64  3770.147  -227.12
 44.529
*127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
0.000
Wed 26 Feb 2020 15:20:54 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
 10.0.7.6LOCAL(1)14 u   42   64  3770.147  -227.12
 73.969
*127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
0.000
Wed 26 Feb 2020 15:23:02 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
*10.0.7.6LOCAL(1)14 u   37   64  3770.164  -370.64
 74.119
 127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
0.000
Time marches on
Wed 26 Feb 2020 16:03:35 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
*10.0.7.6LOCAL(1)14 u   11   64  1770.133   -3.148
 72.295
 127.127.1.1 .LOCL.  14 l  406  128   100.0000.000
0.000
Wed 26 Feb 2020 16:05:43 AEDT
 remote   refid  st t when poll reach   delay   offset
 jitter
==
*10.0.7.6203.35.83.2422 u7   64  3770.164  -42.789
 73.762
 127.127.1.1 .LOCL.  14 l  534  128   200.0000.000
0.000

The debug for the above is:
26 Feb 14:58:33 ntpd[8772]: Command line: /usr/local/sbin/ntpd -c
/etc/ntp.conf -g -g -u ntpd --nofork
...
26 Feb 14:58:34 ntpd[8772]: 10.0.7.6 e014 84 reachable
26 Feb 14:58:35 ntpd[8772]: LOCAL(1) 8014 84 reachable
26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
26 Feb 15:03:40 ntpd[8772]: 0.0.0.0 c515 05 clock_sync
26 Feb 15:22:25 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer  <=== Good!
26 Feb 15:22:25 ntpd[8772]: 0.0.0.0 0613 03 spike_detect -0.370644 s
26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 061c 0c clock_step -0.536289 s
26 Feb 15:30:02 ntpd[8772]: 0.0.0.0 0615 05 clock_sync
26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
26 Feb 15:30:03 ntpd[8772]: 10.0.7.6 e014 84 reachable
26 Feb 15:30:07 ntpd[8772]: LOCAL(1) 8014 84 reachable
26 Feb 15:30:21 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
...
26 Feb 15:46:49 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
26 Feb 15:46:57 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer

...
26 Feb 15:56:58 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
...
26 Feb 16:24:33 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== and stays LOCAL
which is now normal for this box  :(

Should the jump to stratum 14 be expected?  Anything obviously wrong with
the ntp.conf?

I've had a few days of testing on what is usually a very stable (time-wise
system), seems that running at prio 20 is required.

/etc/ntp.conf contains
rlimit memlock -1
rlimit filenum 32
driftfile /var/db/ntp/drift
disable bclient
server 10.0.7.6 iburst minpoll 4 maxpoll 6 version 4 key 23057 prefer

server 127.127.1.1 minpoll 7 maxpoll 7
fudge  127.127.1.1 stratum 14

restrict -4 default ignore
restrict -6 default ignore
restrict 127.0.0.1  nomodify nopeer notrap
restrict -6 ::1 nomodify nopeer notrap
restrict 0.0.0.0 ignore

restrict 10.0.7.6 nomodify nopeer noquery notrap ntpport
restrict 10.169.168.91 mask 255.255.255.0 nomodify nopeer noquery notrap
ntpport kod limited


I'm also very surprised that the jitter on the server (under testing) is so
poor.  The internet facing time server is
*x.y.z.t   .ATOM.   1 u   73  5127   23.776   34.905  95.961
but its very old and not running aslr.

Any ideas or pointers would be appreciated.  This is very, time consuming.
:)

I'm using the following command sequence as these are all being changed
sysctl kern.elf64.aslr.enable=1 kern.elf64.aslr.stack_gap=1
security.mac.ntpd.enabled=1 && \
/usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpdate -v -a
23057  -k /etc/ntp.keys 10.0.7.6 && sleep 2 && \
/rescue/nice -n -20  /usr/bin/proccontrol -m aslr -s disable
 /usr/local/sbin/ntpd -c /etc/ntp.conf -g -g  -u ntpd 

Re: Light GeoIP support dropped?

[Dewayne Geraghty]

Alexander, Unfortunately maxmind have changed their rules and as per
AdamW's notification in the geoipupdate message for version 4.1.5_1,
https://svnweb.freebsd.org/ports/head/net/geoipupdate/files/pkg-message.in?view=markup
advises to go to
https://www.maxmind.com/en/geolite2/signup
to create an account, then you will need to go to (I think it was) "My
Licence" where you provide a key description (you enter text) and then you
will need to generate a key.

Adam advises to go to
https://www.maxmind.com/en/accounts/155743/license-key
for the licence, but that is actually his account number (155743),  which I
would suggest is inappropriate.  (Adam!)  ;)

I have walked through the steps, and the account setup involves providing
you email address, to which additional details are sent for the account
creation process.  Once done, you acquire the key.  Once you login to your
account, you will notice a number at the end of the url, after accounts/
(see above) that is your account information that you plug into your
geoipupdate.conf file, and you'll need your licence key as well.   Its a
little convoluted, but it also provides a config file segment which you can
conveniently cut/paste.

Regards, Dewayne.
PS our version of geoipupdate doesn't provide a version number, but the
current version is 4.1.5_1, anything after 3.1.1 should work as described,
if earlier, the account creation process will advise.  So it continues to
work.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: jexec as user?

[Dewayne Geraghty]

Good question Ronald.

A test - I can login to jail (b3) where I run apache as www user, so
# jexec -U www b3 /bin/tcsh
> whoami; id
www
uid=80(www) gid=80(www) groups=80(www)
Expected - good!

and I can, in the host
# su -m www -c "whoami; id"
www
uid=80(www) gid=80(www) groups=80(www)
Good - so my user exists in both host and jail. Though for your purposes
the host user could be anyone.

So we've demonstrated that I have an unpriv'ed user in both the host and
jailed context.  But
# /usr/bin/su -m www -c "jexec -U www b3 /usr/bin/whoami"
jexec: initgroups: www: Operation not permitted

So unless I/we can identify the cause of this, you're stuck  Which
surprised me, as I typically run stuff in my jails using commands from the
host, like:
/usr/sbin/jexec -U www b3 /usr/local/sbin/httpd -f
/usr/local/etc/apache24/httpd.conf

Now to part 2 of your question.  I do run sshd quite happily in the jails,
so that may be an option for you.  (actually I use dropbear in situations
where I don't required the proper audit logs and its approx 50% of the sshd
resources ;))
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Who should I believe - iostat or mount -v?

[Dewayne Geraghty]

While monitoring various deivces I noticed that the results from mount -v
and iostat weren't the same.  I'm "assuming" that iostat is the more
accurate due to geom tasting (on a memory disk?), or is something else at
play?

Simplest example:
mount -v -t nonullfs |grep md7; iostat -d -c 1  -tda -x -I|grep md7
/dev/md7 on /s (ufs, asynchronous, local, noatime, writes: sync 4 async
268, reads: sync 1215 async 0, fsid 8abeba5db4f71f26)
md7   1244.0   293.0  0.0  0.000.0
  0.0
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Dewayne Geraghty]

Chris,
After you've booted the kernel, the correct way to load a module that isn't
already in the kernel, is to:
kldload mpr
To check if mpr is loaded, try
kldstat -v|grep mpr

However, if you've already placed
mpr_load="YES" in your /etc/loader.conf and rebooted your device, then you
probably need to move into a diagnostic phase.

On Wed, 6 Nov 2019 at 08:04, Chris Ross  wrote:

> On Tue, Nov 05, 2019 at 12:29:00PM -0800, Freddie Cash wrote:
> > > I tried "load", but wasn't able to devine how to load the mpr module
> with
> > > that.  Is that needed, or should 'mpr_load="YES"' have accomplished the
> > > desired result?
> >
> > modulename_load="YES" is the syntax used in the loader.conf file.
> > "load modulename" (without the quotes) is the syntax used at the loader
> > prompt.
> >
> > So at the loader prompt, try the following:  load mpr
> > Or possibly:  load mpr.ko
> > Or, to get right finicky:  load /boot/kernel/mpr.ko
>
> Thanks Freddie and Miroslav.
>
> I tried "load mpr" earler, but it complained it couldn't find it.  I tried
> again a few minutes ago using "load /boot/kernel/mpr.ko", which spun for
> a bit then complained it couldn't load it before the kernel.  I then
> loaded the kernel (by full path), and tried again, with no response.  Just
> an immediate prompt.  I tried "load /boot/kernel/zfs.ko" as well, in case
> mpr.ko was already still in memory, but that also returned an immediate
> prompt
> without saying anything.  So, I think I still have something wrong with my
> attempts to "load".  Should loading the mpr.ko before the kernel work?  It
> didn't with my last attempt (which I realize now was 12.0-RELEASE,
> not 12.1-RELEASE).
>
>- Chris
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>


-- 
*Disclaimer:* *As implied by email protocols, the information in this
message is not confidential. Any intermediary or recipient may inspect,
modify (add), copy, forward, reply to, delete, or filter email for any
purpose unless said parties are otherwise obligated.  Nothing in this
message may be legally binding without cryptographic evidence of its
integrity and/or confidentiality.*
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ASLR affecting ports builds or use-tracking location?

[Dewayne Geraghty]

Where would be the most appropriate place to track ports that are failing
to build/run due to enabling ALSR on FreeBSD12.1Prerelease?

I note that the issue regarding ntp has been addressed (refer
https://reviews.freebsd.org/D21581) but I've also come across another which
failed to run within an ASLR enabled environment, notably clamav-clamd with
the message
LibClamAV Error: mpool_malloc(): Can't allocate memory (16781312 bytes).

Unfortunately as the HardenedBSD folks have demonstrated there will be
other ports that experience ... challenges.
Regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ASLR requirement for images

[Dewayne Geraghty]

>From the comment at https://reviews.freebsd.org/D5603

"The procctl(2) control for ASLR is implemented, [but] I have not provided
a userspace wrapper around the syscall. In fact, the most reasonable
control needed is per-image and not per-process, but we have no
tradition to put the kernel-read attributes into the extattrs of binary,
so I am still pondering that part and this also explains the non-written
tool."

I think its time to revisit the approach.  Storing the attributes within
the extattr is preferable to a central file - we're very fortunate to have
the MAC framework, perhaps a MAC_ASLR is required (to identify those
applications that can/can't use ASLR)?

Other applications also make use of protection bits inside extattr, notably
samba4.

References:
https://reviews.freebsd.org/D19281 mac_veriexec: Create kernel module to
parse manifest based on envs.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ntpd doesn't like ASLR on stable/12 post-r350672

[Dewayne Geraghty]

The data and stack sizes are interesting when comparing ntpd 4.2.7p411 (9.2
from 2014) vs 4.2.8p12 (on 12.1Pre)
 # sh -c 'ntpd --version ; procstat -l $(pgrep ntpd)|grep -E
"data|stack|lock"'
ntpd 4.2.7p411@1.2483-o Sun Mar  9 01:25:57 UTC 2014 (1)
34798 ntpd datasize  524288 kB524288 kB
34798 ntpd stacksize  65536 kB 65536 kB
34798 ntpd memorylocked   32768 kB 32768 kB

ntpd 4.2.8p12-a (1)
46470 ntpd datasize   32768 MB 32768 MB
46470 ntpd stacksize 204800 B 524288 KB
46470 ntpd memorylocked   32768 KB 32768 KB

/usr/local/bin/ntpd only runs with a stack_gap=0 per
kern.elf64.aslr.stack_gap=0
kern.elf64.aslr.honor_sbrk=1
kern.elf64.aslr.pie_enable=1
kern.elf64.aslr.enable=1
kern.elf64.nxstack=1

(incidentally ntpd running with uid ntpd)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dewayne Geraghty]

On 17/05/2018 7:17 AM, Dimitry Andric wrote:
> On 16 May 2018, at 15:54, Mike Tancsa  wrote:
>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>> On 15 May 2018, at 20:22, Mike Tancsa  wrote:
> Anyone else see this ?
>>> See .  There is a fix coming up.
>> I tried the patch and did a full rebuild and it indeed fixed the problem
>> for me.  Is the bug potentially more wide spread that just libxo ? Also
>> does it possibly affect amd64, just in a non obvious way ?
> Yes to both, at least theoretically.  The problem is actually in
> elftoolchain's strip command, which can mess up the TLS section in an
> executable or shared library.  When the dynamic linker loads such a bad
> file, it will setup incorrect TLS data, which can lead to crashes.
>
> In case of libxo.so.0, this appears to have been caused by clang 6
> giving a slightly different ELF layout than clang 5.  During buildworld,
> libxo.so.0 is built with debugging information, which is later copied
> to a libxo.so.0.debug file, while it is removed from the original
> libxo.so.0 file.
>
> Up to this point, everything is still fine with libxo.so.0, still, but
> during installworld, the file is stripped *again*, by install -s (this
> is something we should revisit because it seems no longer useful).  This
> second round of stripping messes up the TLS section.
>
> -Dimitry
>
Revisit? Perhaps, but it seems that its a regression against clang6 over
clang5.  Looking at
https://svnweb.freebsd.org/base?view=revision=333600
its appears that the section flags are correctly applied now.  When
333600 enters 11.1Beta?, do you think the build/installation process
requires revision?

Its a little disappointing to hear that the stripping process breaks the
output, if applied >1.

-- 
Influence national support against IP address spoofing (pretending to be 
someone else), refer: http://www.bcp38.info/index.php/Main_Page

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dewayne Geraghty]

Andre, You're not alone.  I think there's a problem with clang6 on i386
FreeBSD 11.1X, refer:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
and perhaps also on amd64, search for
https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.

Without time to investigate I've reverted userland
FreeBSD 11.2-PRERELEASE  r332843M    amd64 1101515 1101509
FreeBSD 11.2-PRERELEASE  r332843M    i386 1101515 1101509

Apologies for my earlier email, I'd missed setting content-type:
text/plain instead of text/html (the latter strips content to the
mailing list), too many management memo's! ;)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dewayne Geraghty]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Dewayne Geraghty]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Dewayne Geraghty]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Stability of 11.1S

[Dewayne Geraghty]

We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
Feb is in use on our development boxes, however the rebuild on 22nd
resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE 
r329008.  Is anyone actually running a Stable that was built after 22nd
Feb?  Could you please share the revision number?

Because the churn in
https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/ is
high we haven't been able to sight if a problem was identified and
fixed; so we're really looking for a functioning stable that we can
resume tracking.

PS There was no information in the logs, and we have no instrumentation
in the kernel to help. Sorry.

-- 

Influence national support against IP address spoofing (pretending to be 
someone else), refer: http://www.bcp38.info/index.php/Main_Page

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Extended "system" attributes within jailed environment dont work

[Dewayne Geraghty]

On 14/07/2017 5:56 PM, Konstantin Belousov wrote:
> On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote:
>> Can someone advise how I can enable extended attributes in a "system"
>> namespace within a jailed (or bhyve) environment?  There was no guidance
>> in "man jail" nor "man jail.conf".
> Mentioning jails and bhyve in a single sentence clearly indicates serious
> issues with understanding either feature.

Hmm.

> 
>>
>> Simple test
>> >From the host or base system:
>> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
>> /a  first
>> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
>> /a  second
>>
>> Within a jail:
>> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
>> /a  first
>> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
>> setextattr: /a: failed: Operation not permitted
>> getextattr: /a: failed: Operation not permitted
>>
>> The impact of this is that SAMBA after 4.3 uses "system" namespace
>> extended attributes; hence can not provision an Active Directory within
>> a jailed environment.  (For the inclined, this affects sysvol, and
>> interestingly "rsync -x" is unable to copy extended attributes, so
>> having consistent sysvols across a SAMBA domain may be a challenge)
> System namespace access is not allowed for jailed processes by design.
> See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there
> explicitely mentioning the behaviour. The behaviour predates ~ year
> 2002, where extended attributes were introduced, and it makes sense.

Thank-you for the pointer to the source.  With the passage of 15 years
other applications have come to use "system" namespace extended
attributes, as though they were in the host system.  Unfortunately if
you have one physical box available to act as both an authentication
server (Quasi Active Directory) and a fileserver, then using a jailed
environment is the only solution.

By design?  I suppose its akin to saying, why would you want to use
sysvipc from within a jail, with its global namespace (since FreeBSD
V5.0) ; or perhaps the use of raw sockets (FreeBSDv6.0); or mount within
a jail (FreeBSD V9.0); or...?
Probably because sophisticated use of jails is one of the many
outstanding features that sets FreeBSD apart from restrictive and
antiquated environments.  Not all features of a base system should be
reflected in a jail, that would be silly; but where upstream
applications use features, then the enhancement of a jail's
configuration via way of, at least, an option - makes sense.  Doesn't it?

I suppose that the crux to the question is - why should the "system"
namespace not be available within a jail?

Aside: Someone on the SAMBA mailing list also using FreeBSD has a
similar problem, but he's using bhyve - hence the use within the same
sentence.

Regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Extended "system" attributes within jailed environment dont work

[Dewayne Geraghty]

Can someone advise how I can enable extended attributes in a "system"
namespace within a jailed (or bhyve) environment?  There was no guidance
in "man jail" nor "man jail.conf".

Simple test
>From the host or base system:
# touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
/a  first
# touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
/a  second

Within a jail:
# touch /a ; setextattr user t1 first /a ; getextattr user t1 /a
/a  first
# touch /a ; setextattr system t2 second /a ; getextattr system t2 /a
setextattr: /a: failed: Operation not permitted
getextattr: /a: failed: Operation not permitted

The impact of this is that SAMBA after 4.3 uses "system" namespace
extended attributes; hence can not provision an Active Directory within
a jailed environment.  (For the inclined, this affects sysvol, and
interestingly "rsync -x" is unable to copy extended attributes, so
having consistent sysvols across a SAMBA domain may be a challenge)

Regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dd is returning different content using same inputs

[Dewayne Geraghty]

Yes, it does.

Thank you.
-- 
*Disclaimer:* *As implied by email protocols, the information in this
message is not confidential. Any intermediary or recipient may inspect,
modify (add), copy, forward, reply to, delete, or filter email for any
purpose unless said parties are otherwise obligated.  Nothing in this
message may be legally binding without cryptographic evidence of its
integrity and/or confidentiality.*
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

dd is returning different content using same inputs

[Dewayne Geraghty]

I'm attempting to skip the first three bytes of a file and then pull the
header out of message. Please note the file size varies between 105 and 54
bytes, even though the input file and everything else remains constant, on

FreeBSD hathor 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 r319562M: Mon
Jun  5 03:13:08 AEST 2017 root@hathor:/110007/D/K8/hqdev-amd64-smp-vga
amd64 1100514 1100514

# rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384 count=1
of=encheader ; ls -lrth  encheader
0+1 records in
0+1 records out
105 bytes transferred in 0.26 secs (4071661 bytes/sec)
-rw-r--r--  1 root  wheel   105B Jun  8 16:35 encheader
# rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384 count=1
of=encheader ; ls -lrth  encheader
0+1 records in
0+1 records out
67 bytes transferred in 0.26 secs (2554912 bytes/sec)
-rw-r--r--  1 root  wheel67B Jun  8 16:35 encheader
# rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384 count=1
of=encheader ; ls -lrth  encheader
0+1 records in
0+1 records out
68 bytes transferred in 0.24 secs (2867263 bytes/sec)
-rw-r--r--  1 root  wheel68B Jun  8 16:35 encheader
# rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384 count=1
of=encheader ; ls -lrth  encheader
0+1 records in
0+1 records out
54 bytes transferred in 0.25 secs (2167717 bytes/sec)
-rw-r--r--  1 root  wheel54B Jun  8 16:35 encheader
# rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384 count=1
of=encheader ; ls -lrth  encheader
0+1 records in
0+1 records out
91 bytes transferred in 0.24 secs (3751494 bytes/sec)
-rw-r--r--  1 root  wheel91B Jun  8 16:35 encheader

I used this around May 8th (from a OS and ports rebuild on 4th May) and was
performing some final testing on an 11.1 Prerelease built on Jun 5.

This works correctly so perhaps I'm not using dd correctly?
dd if=/tmp/tLbdoJ/encmessage skip=1 bs=3  | dd bs=1 count=384 of=encheader
; hd encheader|head -n1; ls -l encheader
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 11.0: Installation of icingaweb2

[Dewayne Geraghty]

Thorsten,
This is a ports issue so should go to the freebsd-ports mailing list (if at
all)

Your best option is to file a PR so that the maintainer of the port can
update the plist file.  You'll occassionally see this sort of package-build
failure when the maintainer has missed a test package step.

If you're shy, you could write to the maintainer directly but then others
can't see that the issue has been raised (and presumably being
raised/addressed).

In the meantime - you could adjust the plist yourself to reflect the new
reality.  Though expedient this is not recommended.  Filing a PR is highly
recommended to benefit everyone and have a fix properly applied.
Regard.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

How to turn off SSP stack-protector on 11.0S

[Dewayne Geraghty]

Is WITHOUT_SSP actually honoured and is building a world and/or ports
without SSP possible? Advise/suggestions appreciated.

Amongst the 9 different server configurations that we build/support, we've
been asked to build a machine dedicated to PROLOG use.  (yes really).

As such we're trying to turn off everything that isn't needed for this
particular server.  For those concerned with security, it is an air-gap
machine receiving data via usb.

We've built/installed 11.0S from source.  Now we're building the custom
server.  However, even with WITHOUT_SSP= in both /etc/make.conf and
/etc/src.conf, we come up against little issues like:
"can not find /usr/lib/libssp_nonshared.a"

An example:
Stage 2.3: build tools
===> bin/csh (obj,build-tools)
grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define'
>> sh.err.h
cc -E -O2 -pipe -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UDEBUG
-DUSB_HAVE_DISABLE_ENUM -I. -I/usr/src/bin/csh
-I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -g
-std=gnu99 -Qunused-arguments
-I/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/include
/usr/src/bin/csh/../../contrib/tcsh/tc.const.c
/usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h
/usr/src/bin/csh/../../contrib/tcsh/config_f.h
/usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const |
grep 'Char STR' |  sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char
\1[];/' |  sort >> tc.const.h
cc -o gethost  -L/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/lib -O2
-pipe -g0 -ggdb0 -DSTRIP_FBSDID  -UDEBUGGING -UDEBUG
-DUSB_HAVE_DISABLE_ENUM -I. -I/usr/src/bin/csh
-I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -g
-std=gnu99 -Qunused-arguments
-I/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/include
/usr/src/bin/csh/../../contrib/tcsh/gethost.c
/usr/bin/ld: cannot find /usr/lib/libssp_nonshared.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [gethost] Error code 1

Note the
/usr/bin/ld: cannot find /usr/lib/libssp_nonshared.a

It seems that the linker is trying to use the above library during the
build of all static images/executables.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Benchmarks results for FreeBSD 11

[Dewayne Geraghty]

Unfortunately people (customers, developers, hardward vendors) make
decisions on the basis of bang-for-buck.  FreeBSD is consistently
underperforming on benchmarks.  And regardless of real-world similarity,
the contrived benchmarks are the best that is used.

If clang (v3.4.1 on 10.3 Stable)  really is the cause, then there should be
an option to use "whatever" will let the source perform at its best and
reflect the stability that we have with FreeBSD.

We can criticise the test results or the test regime, but unless
knowledgable people respond publicly and/or in the phoronix forums, such as
https://www.phoronix.com/forums/forum/software/distributions/891660-benchmarks-2-bsds-vs-7-linux-distributions
Then this interpretation of reality will be fixed in decision-makers' minds
and consequently the uptake (and support) of FreeBSD.

As I recall Michael's testing regime has been consistently criticised (by
FreeBSD folks) since he started his website, unfortunately when someone is
making public statements and comparisons we really need to have a
relationship with them to ensure that FreeBSD's best position is put
forward.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Problem with /usr/lib/libcrypt.a when building perl/python with libressl

[Dewayne Geraghty]

I'm trying to rebuild my local ports tree using libressl.  Unfortunately
the linker is advising that I should build /usr/lib/libcrypt.a with -fPIC.
As its a security-related module, I would appreciate advise as to whether
this will/may cause a security issue?

The message, during the link phase, that both python27 and perl 5.20 is
sending is:
/usr/bin/ld: /usr/lib/libcrypt.a(crypt.o): relocation R_X86_64_32 against
`a local symbol' can not be used when making a shared object; recompile
with -fPIC
/usr/lib/libcrypt.a: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)

I understand the value of fPIC for shareable libraries but I'm a little
confused as to why libcrypt.a requires -fPIC; which BTW does enable both
python, perl and others to build cleanly.

Regards, Dewayne
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problems with powerd and cpufreq on AMD Quad-Core A8-4555M

[Dewayne Geraghty]

Bottom posted

On 29 February 2016 at 12:36, John <freebsd-li...@potato.growveg.org> wrote:

> On Mon, Feb 29, 2016 at 08:29:14AM +1100, Dewayne Geraghty wrote:
>
> Thanks John, I have cpufreq added via the boot/loader.conf which always
>> works. However, over the weekend, I was testing some boot changes and
>> tried
>> to add cpufreq AFTER the kernel - unsuccessfully.  This was amd64
>> 10.3Beta1
>> and 10.3Beta3.
>>
>> A workaround (for you) might be to remove it from the kernel and load
>> cpufreq via loader.conf?
>>
>> I have some other problems (with usb nic's axge,axe) but I'll pursue if I
>> get time for enough info for a PR
>>
>
> Hi Dewayne,
>
> Thanks for looking at this. I modified loader.conf:
>
> $ cat /boot/loader.conf
> cpufreq_load="YES"
>
> then recompiled the kernel and rebooted:
>
> 10.3-BETA3 #1 r296151
>
> root@onion:~ # kldstat
> Id Refs AddressSize Name
> 1   13 0x8020 d45380   kernel
> 21 0x80f46000 f0c8 cpufreq.ko
> 31 0x8113d000 1604 fdescfs.ko
> 41 0x8113f000 946  pflog.ko
> 51 0x8114 2d0efpf.ko
> ...but still no-go:
>
> root@onion:~ # powerd -v
> powerd: no cpufreq(4) support -- aborting: No such file or directory
>
> Also commented out the powerd entries from /etc/rc.conf, rebooted
> again, no difference.
>
> many thanks,
>
> --
> John
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>

That's a nuisance!

As I said, IF I load the module before the kernel, I'm good as follows.
However if I load after booting, then I don't have any frequencies to
choose from.

I'm afraid the only "help" I can provide is of my working situation :(  The
order might be relevant.


This is the early part of my /boot/loader.conf
kern.hz="250"

kern.coredump="0"
loader_logo="none"
beastie_disable="YES"
autoboot_delay="1"

kern.geom.label.ext2fs.enable="0"
kern.geom.label.reiserfs.enable="0"

cpufreq_load="YES"
coretemp_load="YES"
mac_ifoff_load="YES"

-
kldstat
 1   20 0x8020 aef9a8   kernel
 21 0x80cf 2cc0 coretemp.ko
 31 0x80cf3000 ef38 cpufreq.ko
 41 0x80d02000 2b60 mac_ifoff.ko

# sysctl -e dev.cpu.0.freq_levels
dev.cpu.0.freq_levels=1801/25000 1800/25000 1700/23232 1600/21501
1500/20046 1400/18382 1300/16988 1200/15393 1100/14060 1000/12527 900/11252
800/9783

# /etc/rc.d/powerd onestart
Starting powerd.
# ps -axww|grep power
32365  -  Ss0:00.00 /usr/sbin/powerd
32382  5  S+0:00.00 grep power

Then I
/usr/sbin/powerd -vv
load   0%, current freq 1801 MHz ( 0), wanted freq 1744 MHz
changing clock speed from 1801 MHz to 1800 MHz
load   0%, current freq 1800 MHz ( 1), wanted freq 1689 MHz
changing clock speed from 1800 MHz to 1700 MHz
load   0%, current freq 1700 MHz ( 2), wanted freq 1636 MHz
load   0%, current freq 1700 MHz ( 2), wanted freq 1584 MHz

So its working as expected.  (I used to make extensive use of powerd, but
my customers' wanted top performance during the day, so I adjust the CPU
frequencies instead, based on time.)

As I might have mentioned, if I load after the kernel, then kldload will
show cpufreq.ko but there will be no frequencies to choose from.

Might be relevant??
Kind regards, Dewayne
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problems with powerd and cpufreq on AMD Quad-Core A8-4555M

[Dewayne Geraghty]

Thanks John, I have cpufreq added via the boot/loader.conf which always
works. However, over the weekend, I was testing some boot changes and tried
to add cpufreq AFTER the kernel - unsuccessfully.  This was amd64 10.3Beta1
and 10.3Beta3.

A workaround (for you) might be to remove it from the kernel and load
cpufreq via loader.conf?

I have some other problems (with usb nic's axge,axe) but I'll pursue if I
get time for enough info for a PR
Regards.


On 29 February 2016 at 02:18, John  wrote:

> Hello list,
>
> I'm using 10.3-BETA3 #0 r296148 compiled today on on AMD Quad-Core
> A8-4555M. I have the following in /etc/rc.d:
>
> powerd_enable="YES"
>
> I have cpufreq in the kernel config, unmodified GENERIC apart from adding a
> line for amdtemp.
>
> # CPU frequency control
> device  cpufreq
>
> Why is it that on boot I get the following warning:
>
> powerd: no cpufreq(4) support -- aborting: No such file or directory
>
> Does powerd not work with AMD ? Some debugging info:
>
> root@onion:~ # sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
> hw.machine: amd64
> hw.model: AMD A8-4555M APU with Radeon(tm) HD Graphics   hw.ncpu: 4
> hw.machine_arch: amd64
>
> root@onion:~ # sysctl debug.hwpstate_verbose="1"
> debug.hwpstate_verbose: 0 -> 1
> root@onion:~ # powerd -v
> powerd: no cpufreq(4) support -- aborting: No such file or directory
>
> thanks,
> --
> John ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE

[Dewayne Geraghty]

On 20 February 2016 at 09:01, Bryan Drewery  wrote:

> On 2/6/2016 6:21 AM, Jim Ohlstein wrote:
> > Hello,
> >
> > First noticed:
> >
> > root@rubicon:/usr/src # svn info
> > Path: .
> > Working Copy Root Path: /usr/src
> > URL: https://svn.freebsd.org/base/stable/10
> > Relative URL: ^/stable/10
> > Repository Root: https://svn.freebsd.org/base
> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > Revision: 295341
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: marius
> > Last Changed Rev: 295289
> > Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016)
> >
> >
> > Still present:
> >
> > root@rubicon:/usr/src # svn info
> > Path: .
> > Working Copy Root Path: /usr/src
> > URL: https://svn.freebsd.org/base/stable/10
> > Relative URL: ^/stable/10
> > Repository Root: https://svn.freebsd.org/base
> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > Revision: 295351
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: wblock
> > Last Changed Rev: 295350
> > Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016)
> >
> >
> > root@rubicon:/usr/src # make clean && make buildworld
> >
> >
> > [snip]
> >
> >
> >
> > cc   -O2 -pipe   -I. -DINET6 -DFTP_COMBINE_CWDS -std=iso9899:1999
> > -Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wall
> > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> > -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  -c
> > /usr/src/lib/libfetch/common.c -o common.o
> > /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL'
> > [-Werror,-Wunused-parameter]
> > fetch_ssl(conn_t *conn, const struct url *URL, int verbose)
> >   ^
>
>
> Try this patch please:
> https://people.freebsd.org/~bdrewery/patches/libfetch-unused-ssl.patch


>
>
> --
> Regards,
> Bryan Drewery
>
>
Unfortunately, I think you'll find that you'll need openssl for:
libarchive, geom_eli, tar and gssd as well.
Good luck (I tried a few years ago but failed because I really needed
geli).
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problem with geli and LSI controller

[Dewayne Geraghty]

On 20/07/2015 5:56 PM, Marc UBM Bocklet wrote:
 On Sun, 19 Jul 2015 09:16:51 -0700
 John-Mark Gurney j...@funkthat.com wrote:

 Marc UBM via freebsd-stable wrote this message on Sun, Jul 19, 2015 at 17:34 
 +0200:
 a few weeks ago our Highpoint Rocket Raid controller (hptrr) started
 biting the dust (spurious channel resets). We bought a LSI 9201-16i
 (mps) to replace it. Connected to the hptrr were 4 external e-sata
 enclosures, configured in JBOD mode. Together with two disks connected
 to the onboard SATA controller, this formed a geli encrypted raidz-2
 zpool. 
 Just now, I connected the disks to the mps controller. They show
 up fine in dmesg. The problem is, when trying to attach the disks
 formerly connected to the hptrr controller, geli is unable to find the
 metadata on the disks and errors out with:

 geli: Cannot read metadata from /dev/da4: Invalid argument

 gpart show says gpart: No such geom: da4

 Trying to restore the geli metadata gives:
 geli: Provider size mismatch: wrong backup file?

 Is it possible that the hptrr controller handled the disks in some
 special way and it's only possible to read them there?
 This sounds like the drives were in raid0 mode, and not raw disk
 mode...  You might be able to recover the disk w/ geli resize,
 assuming only space was added at the end, not at the begining, but
 I have never personally tried that myself...  I'd recommend trying
 on a copy of the drive so you don't loose data if that is possible..

 You can also try to find the old geli label w/ a command like:
 dd if=disk bs=1m iseek=location count=5 | strings -n 9 -td

 And get current disk size using diskinfo...

 Something like:
 #diskinfo /dev/ada0
 /dev/ada0   512 3000592982016   5860533168  40960   
 5814021 16  63
 #dd if=/dev/ada0 iseek=$((3000592982016/1024/1024-1)) bs=1m 2/dev/null | 
 strings -n 6 -td | grep GEOM::
 1530880 GEOM::ELI
 1531392 GEOM::LABEL

 You might have to go farther back than 1 MB...

 Good luck...
 No luck so far, diskinfo gives me:

 #diskinfo da4
 da4 512 2000398934016   3907029168  40960   243201 255
  63

 but
 #dd if=/dev/da4 iseek=$((2000398934016/1024/1024-1)) bs=1m 2/dev/null | 
 strings -n 6 -td | grep GEOM::
 yields nothing.
Marc,
Sometimes shell scripts calculations can be daunting.  Refer to this

$((2000398934016/1024/1024-1))

Now the following portion which converts bytes to MB

2000398934016/1024/1024
that is, dividing bytes by 1M (first by 1KB=1024 then again, means its 
effectively 1Meg)

and you have then subtracted 1 MB from it.  To step further back from
the end of the hard-disk, you could, for example go back 2MB

$((2000398934016/1024/1024-2))

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: WITHOUT_OPENSSL and make delete-old

[Dewayne Geraghty]

On 14/07/2015 12:03 AM, Matt Smith wrote:
 Hi, I use the ports version of OpenSSL for everything and don't
 require the base version. As a result I thought I would remove it by
 adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old
 in /usr/src. However this seems to only want to delete things related
 to kerberos and gssapi, which is understandable as they depend on
 OpenSSL.  However it doesn't seem to touch any OpenSSL files at all.
 Is this a bug or have I missed something?


Matt, I've been down that road.  And for a few years, I installed
openssl port over openssl base.  But things have changed a lot, geli
uses openssl headers, libarchive (hence tar, cpio) and libarchive need
openssl; and of course kerberos, openssh).  Also, if you remove gssapi
then you won't be build gssd (used for kernel/NFS gssapi). 

The way I get around this issue is to build a base system that uses
base openssl to build the necessary base components, using
WITHOUT_[KERBEROS,OPENSSH].  Using this base system, I build a couple of
jails, which are used to build the ports.  For these jails I remove any
remnants of base openssl.  Then I'm able to build everything and install
onto the production servers only what they need.  (Pay attention to
where base openssl places libcom_err.*, it sometimes slips through. I
have a PR for this; and a build script removes it).

What you loose?  The FreeBSD version of openssl is tweaked by very
knowledgeable members (both Dag-Erling Smorgrav and John-Mark Gurney et
al), so you may want to examine their changes.

There is/was talk about making base openssl - private which I believe
will accomplish the same result: base openssl for the base system, and
port openssl for port building.  I don't have details or timeline for
these changes.

Why did I bother? Historically - I installed heimdal 1.0.1 while base
heimdal was at 0.6.3. And for my use case: no nfs, needed additional
ciphers (at the time) and a slightly different attack surface; my build
system works.  :)

I hope I've save you some time.
Regards, Dewayne.

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

System load greater than logical cores and idprio 30 getting time.

[Dewayne Geraghty]

I don't understand why processes running at idpro 30 are gettting as
much CPU time as stated below when the load average is greater than the
number of logical cores.  I don't think its just a measuring error as I
have other short lived processes that also complete at idprio 31.  The
scheduler for this server is
kern.sched.name: ULE
kern.sched.interact: 0

This top extract was taken from a Xeon E3-1230L with 8 logical cores,
running 10.1Stable built/installed May 6,2015.

-- top extract --
last pid: 83135;  load averages: 11.32,  8.98, 
6.24  up 1+01:33:51  14:42:19
81 processes:  13 running, 68 sleeping
CPU: 95.9% user,  0.0% nice,  4.1% system,  0.0% interrupt,  0.0% idle
Mem: 299M Active, 5507M Inact, 1351M Wired, 5580K Cache, 899M Buf, 568M Free
Swap: 3881M Total, 16M Used, 3865M Free

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
COMMAND
40867 root  1 154  i30 50316K  4720K RUN 2  17:59  42.97%
ssh-keygen
40869 root  1 154  i30 50316K  4728K RUN 6  17:49  42.48%
ssh-keygen
83099 root  1  760 86468K 70696K RUN 4   0:02  16.46% c++

And couple of hours later (note not WCPU)

last pid: 21436;  load averages: 20.13, 14.73,
12.00  up 1+04:15:45  17:24:13
101 processes: 23 running, 78 sleeping
CPU: 95.6% user,  0.0% nice,  4.4% system,  0.0% interrupt,  0.0% idle
Mem: 724M Active, 5292M Inact, 1241M Wired, 32M Cache, 847M Buf, 443M Free
Swap: 3881M Total, 21M Used, 3861M Free

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIME CPU
COMMAND
20141 root  1 155  i31 83084K 37688K RUN 7   0:09  25.98%
ssh-keygen
21380 root  1  790   110M   101M CPU33   0:03  24.46% c++
21340 root  1  780 74492K 66468K CPU44   0:03  20.46% c++

I recall the BSD scheduler behaving as expected, ie when the load 
cores, then idprio 31 processes barely received any time.

Regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Problems with openssl 1.0.2 update

[Dewayne Geraghty]

On 24/03/2015 12:16 AM, Gerhard Schmidt wrote:
 On 23.03.2015 13:40, Guido Falsi wrote:
 On 03/23/15 11:33, Gerhard Schmidt wrote:
 Hi,

 we experiencing a problem after upgrading  the openssl port to openssl
 1.0.2.

 /usr/bin/vi started to crash after some seconds with segfault.
 /rescue/vi works just fine. Deleting the openssl 1.0.2 package
 everything works just fine again. Installing the old openssl 1.0.1_18
 package it still works just fine.

 it seams that besides vi the bash also has this problem. Anybody
 experiencing the same or is this something specific to my system.

 I'm running FreeBSD 10.1 updated tonight.
 I am seeing runtime problems with asterisk13 (which I maintain), caused
 by the OpenSSL update fallout.

 In this case, after some analysis, I concluded the problem is the
 libsrtp port requiring OpenSSL from ports(for a reason), causing
 asterisk to link to that too, which would be correct.

 Asterisk also uses the security/trousers port, which links to system
 OpenSSL. This ensues a conflict which now results in asterisk
 segfaulting and stopping to work.

 I'm investigating what can be done about this. As a local solution I can
 force the trousers port to link against OpenSSL from ports, but this
 will not fix the general problem. As a port maintaner I ony see
 modifying the trousers port to depend on ports OpenSSL as a solution, is
 this acceptable?

 Most Ports link against the port openssl if its installed and agains the
 system openssl if not. That should be the prefered way to handle problem.

 I don't know if an incompatibility between system an port openssl is a
 problem. I've removed the portbuild openssl from this server completely.

 As far as i can see the problem is with openldap-client build agains the
 ports openssl and used by nss_ldap or pam_ldap modul. I will do some
 testing when my test host is ready. Testing on an Production server is
 not that good :-)

 Regards
Estartu


I only use openssl from ports and have just completed a rebuild of 662
packages for server requirements and include: trousers, ldap client and
server, and 71 other ports built without any issues on amd64 10.1Stable
using clang.  Not so successful on i386 but I don't believe its related
to openssl.

My 2c.
Regards, Dewayne
PS Of the ports I use, only ports-mgmt/pkg and sysutils/monit link
against base openssl as they don't provide an option. :(

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

buildworld without libncursesw

[Dewayne Geraghty]

Is there a preferred way to buildworld without libncursesw?

When I add to /etc/src.conf
WITHOUT_NCURSESW=yes

I find that a buildworld fails due to missing libncursesw.*.
So what uses libncurses?  These guys do
/usr/bin/dialog
/usr/bin/dpv
 
/usr/sbin/sade - /usr/libexec/bsdinstall/partedit
/usr/sbin/tzsetup

Getting a little frustrated I modifed the Makefile:, so for example
dialog (/usr/src/contrib/dialog)

+.include bsd.own.mk
+
+.if ${MK_NCURSESW} == no
+DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSES}
${LIBUTIL} ${LIBM}
+LDADD= -ldpv -ldialog -lfigpar -lncurses -lutil -lm
+.else
 DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSESW}
${LIBUTIL} ${LIBM}
 LDADD= -ldpv -ldialog -lfigpar -lncursesw -lutil -lm
+.endif

And checking
# make -VMK_NCURSESW
no

I'm at a bit of a loss as to why these are proving difficult to build,
or what I can do to get the desired outcome, ie no libncursesw.so*
Dewayne.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: buildworld without libncursesw

[Dewayne Geraghty]

On 4/03/2015 8:13 AM, Brooks Davis wrote:
 On Tue, Mar 03, 2015 at 08:20:57PM +1100, Dewayne Geraghty wrote:
 Is there a preferred way to buildworld without libncursesw?

 When I add to /etc/src.conf
 WITHOUT_NCURSESW=yes

 I find that a buildworld fails due to missing libncursesw.*.
 So what uses libncurses?  These guys do
 /usr/bin/dialog
 /usr/bin/dpv
  
 /usr/sbin/sade - /usr/libexec/bsdinstall/partedit
 /usr/sbin/tzsetup

 Getting a little frustrated I modifed the Makefile:, so for example
 dialog (/usr/src/contrib/dialog)

 +.include bsd.own.mk
 +
 +.if ${MK_NCURSESW} == no
 +DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSES}
 ${LIBUTIL} ${LIBM}
 +LDADD= -ldpv -ldialog -lfigpar -lncurses -lutil -lm
 +.else
  DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSESW}
 ${LIBUTIL} ${LIBM}
  LDADD= -ldpv -ldialog -lfigpar -lncursesw -lutil -lm
 +.endif

 And checking
 # make -VMK_NCURSESW
 no

 I'm at a bit of a loss as to why these are proving difficult to build,
 or what I can do to get the desired outcome, ie no libncursesw.so*
 I tried to make this work a while ago and it's not practical.  Instead,
 we need to remove libncurses (or more likely replace it with a linker
 script to cause libncursesw to be used.)

 It should be the case that nothing in the base system uses libncurses,
 but it's all too likely that someone has broken that since I switched
 the remaining bits over.

 -- Brooks
Unfortunately I can't say which ones use libncurses as I've sprinkled
things like this over anything that uses libncursesw

-DPADD= ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} ${LIBBSDXML} ${LIBSBUF}
${LIBEDIT} ${LIBNCURSESW}
-LDADD= -ldevstat -lkvm -lgeom -lbsdxml -lsbuf -ledit -lncursesw
+DPADD= ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} ${LIBBSDXML} ${LIBSBUF}
${LIBEDIT}
+LDADD= -ldevstat -lkvm -lgeom -lbsdxml -lsbuf -ledit

+.include bsd.own.mk
+
+.if ${MK_NCURSESW} == no
+DPADD+= ${LIBNCURSES}
+LDADD+= -lncurses
+.else
+DPADD+= ${LIBNCURSESW}
+LDADD+= -lncursesw
+.endif
+

and only the above 4 programs are more of a challenge.

Any consistency is a good thing, so honouring WITHOUT_NCURSESW should be
the trigger.  This situation arose because I needed some things in
/rescue and there was a conflict stuffing both libncurses and
libncursesw into the /usr/src/rescue build, as you'd expect. :)

Regards, Dewayne.

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Suggest changing dirhash defaults for FreeBSD 9.2.

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Ivan Voras
 Sent: Wednesday, 28 August 2013 7:49 PM
 To: freebsd-stable@freebsd.org
 Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2.
 
 On 28/08/2013 05:58, Robert Burmeister wrote:
  
  On 8/27/2013 9:40 AM, Sergey Kandaurov wrote:
  On 27 August 2013 16:41, Robert Burmeister 
  robert.burmeis...@utoledo.edu  wrote:
  I have been experimenting with dirhash settings, and have scoured 
  the internet for other peoples' experience with it.
  (I found the performance improvement in compiling has forestalled 
  the need to add an SSD drive. ;-)
 
  I believe that increasing the following values by 10 
 would benefit 
  most FreeBSD users without disadvantage.
 
  vfs.ufs.dirhash_maxmem: 2097152 to 20971520
 
  vfs.ufs.dirhash_reclaimage: 5 to 50 or 60
  vfs.ufs.dirhash_maxmem is further autotuned based on available 
  physical memory.
  See r214359 for details.
 
  [Spock Eyebrow of Thought]
  
  I'm running FreeBSD i386 9.2, that allows a max of 4 Gigs of RAM.
 
 To what value does the algorithm tune in your case? On my 16 
 GB machine, it's ~~ 25 MB:
 
 vfs.ufs.dirhash_maxmem: 26968064
 
  I think the algorithm is still overly conservative for 32 
 bit systems, 
  which are more likely to be using UFS.
  
  As 64 bit platforms tend to have more RAM and use ZFS, is the same 
  tuning algorithm appropriate for both?
 
 The policy is to use fractions of the installed RAM (though 
 in a roundabout way), so it should scale reasonably well to 
 both systems with large and small memories.
 
 I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it.
 
 
 

Ivan, 
From the analysis perforned in 2009, and referenced earlier by Robert, this
https://wiki.freebsd.org/DirhashDynamicMemory and other material at this site,
indicates that the reclaimage interval is workload dependent and that 5 to 8 
seconds seems, on average, to be adequate.

We perform quite a detailed analysis before changing our sysctls for customers' 
servers that range from 32bit machines with between
1G and 4G of memory, and 64bit with 30G of memory, incidentally all are UFS2. 
Is the discussion, rather than (synthetic) workload
performance, sufficient to warrant changing the default settings by a factor of 
12? 

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Behavior of jexec

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of 
 Florent Peterschmitt
 Sent: Friday, 16 August 2013 3:24 AM
 To: freebsd-stable@freebsd.org
 Subject: Behavior of jexec
 
 Hi,
 
 I noticed two things when running jexec. I run FreeBSD 
 9.2-RC1 from binaries and jails 9.2-RC1 too.
 
 I log as root on the host (I havn't any other user).
 
 # 1. $HOME
 
 For a jail named blog with a blog user, which $HOME is at 
 /home/blog, if I do:
 
 jexec -U blog blog tcsh
 
 My id is correct, but $HOME is still root.
 
 # 2. Accessing a jail in ssh command line
 
 I'm on my client machine and want to get on the server 
 machine, where jails are, and I want to do a jexec from ssh 
 command line:
 
 ssh katana jexec -U blog blog tcsh
 
 I get a connection (trusting /var/log/auth) but it hangs on 
 and do nothing. Event with a simple ls as jail command.
 
 Thanks.
 
 
 -- 
 Florent Peterschmitt   | Please:
 flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
 +33 (0)6 64 33 97 92   |  * Send PDF for documents.
 http://florent.peterschmitt.fr | Thank you :)
 
 

The behaviour is roughly what should be expected.  

It's helpful to keep in mind that the jail isn't running a getty or login 
process in the context of the jail. So using 
jexec -U blog blog tcsh
you'll acquire the correct ID, but be dropped into '/'.  Reading the jail code 
might be the only definitive statement as to why.

When you ssh into the jail, there is no tty assigned to the session.  You can 
force a tty by
ssh -t katana jexec -U blog blog tcsh
Which should give you what you require, a shell within the jail context and an 
id of blog.

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: status of autotuning freebsd for 9.2

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Alfred 
 Perlstein
 Sent: Tuesday, 20 August 2013 2:05 AM
 To: Outback Dingo
 Cc: r...@freebsd.org; sta...@freebsd.org; Andre Oppermann; 
 nones...@longcount.org
 Subject: Re: status of autotuning freebsd for 9.2
 
 Performance is bad for large memory requirements period. 
 
 Vnodes and mbufs on a machine with 24gb ram is limited to the 
 same amount as a machine with less than 4GB ram. 
 
 This was fixed in head but not merged back in time. 
 
 This results in poor out of the box performance on 10gige and 
 servers with high vnode requirements.  
 
 Sent from my iPhone
 
 On Aug 19, 2013, at 7:30 AM, Outback Dingo 
 outbackdi...@gmail.com wrote:
 
  
  
  
  On Mon, Aug 19, 2013 at 10:26 AM, Alfred Perlstein 
 alf...@ixsystems.com wrote:
  
  
  On Aug 19, 2013, at 2:52 AM, Andre Oppermann 
 an...@freebsd.org wrote:
  
   On 16.08.2013 10:29, Andre Oppermann wrote:
   On 16.08.2013 08:32, Alfred Perlstein wrote:
   Andre, I'm kind of bummed out this didn't make it into 
 9.2, I'm 
   wondering can I commit this to 9-stable now?  (or is 
 it already 
   in?)
  
   It didn't make it because there was only sparse 
 feedback after the 
   call for testers.  There were a couple of replies that 
 it is being 
   tested but no statements either way if it was good or 
 not.  Hence 
   I erred on the side of caution and refrained from committing it.
  
   Revisiting the history of this after vacation absence actually 
   shows that we straddled the release code freeze deadline and you 
   had provided good testing feedback.  However the MFC got 
 rejected 
   by RE on the fear of introducing unknown regressions 
 into the release process.
  
   Would you do the honors?
  
   Yes, will do later today.
  
   Committed to stable/9 as r254515.
  
   Let me know if there are any issues.
  
  Thanks Andre.
  
   Maybe we can do a point release/patch release with this 
 in a few weeks for 9.2.1 or 9.2p1 because 9.2 out of the box 
 performance is abysmal not only in networking but also disk 
 as maxvnodes is clipped way too small even with plenty of ram.
  
  So your saying, 9.2-RELEASE performance suffers degradation against 
  say 9.1 ?? are you referring to with this patch enabled? or just in 
  general 9.2-RELEASE
   
  
   --
   Andre
  
  ___
  freebsd-stable@freebsd.org mailing list 
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org
  
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org

It might be relevant that there were performance changes to nullfs (caching) 
code back in January and updated in May by Kib. Because
I use jails and nullfs extensively, the nullfs enhancement demanded an increase 
in maxvodes, otherwise performance degraded, quite
badly.  Tripling the default suited my needs on 4GB systems, but I don't have 
an algorithmic recommendation; as for me it depends on
the role/purpose of the server.  

If vnodes is an issue *and* you use mount_nullfs, another approach is to 
disable caching via 
mount_nullfs -o nocache as this may help to narrow the cause.

Ref:
http://svnweb.freebsd.org/base/stable/9/sys/fs/nullfs/null_subr.c?view=log
http://lists.freebsd.org/pipermail/svn-src-stable-9/2013-May/004531.html

And thank-you for your work on 
http://lists.freebsd.org/pipermail/svn-src-stable-9/2013-August/005307.html

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: ipv6_addrs_IF aliases in rc.conf(5)

[Dewayne Geraghty]

Sato-san,

You have provided a very useful summary of ifconfig parameters for rc.conf. 
However, you are missing one example that would provide
clearer understanding.  Would you please advise if 
 
ipv4_addr_em0=10.2.1.1-10/32

is deprecated, backward compatible or remains valid into the future?

I particularly appreciate the succinctness of:
ifconfig_em0_aliases=inet 10.3.3.201-204/24 inet6 2001:db8:210-213::1/64 inet 
10.1.1.1/24

Kind regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: new jail(8) ignoring devfs_ruleset?

[Dewayne Geraghty]

An ugly workaround to complete the jail closure, when relying on jail.conf, is 
to:

jail -r $JAILNAME
umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Nullfs leaks i-nodes

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Mikolaj Golub
 Sent: Wednesday, 8 May 2013 6:42 AM
 To: Göran Löwkrantz
 Cc: Kostik Belousov; freebsd-stable@freebsd.org
 Subject: Re: Nullfs leaks i-nodes
 
 On Tue, May 07, 2013 at 08:30:06AM +0200, Göran Löwkrantz wrote:
  I created a PR, kern/178238, on this but would like to know 
 if anyone has 
  any ideas or patches?
  
  Have updated the system where I see this to FreeBSD 
 9.1-STABLE #0 r250229 
  and still have the problem.
 
 I am observing an effect that might look like inode leak, which I
 think is due free nullfs vnodes caching, recently added by kib
 (r240285): free inode number does not increase after unlink; but if I
 purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0
 and observing vfs.freevnodes decreasing to 0) the inode number grows
 back.
 
 You have only about 1000 inodes available on your underlying fs, while
 vfs.wantfreevnodes I think is much higher, resulting in running out of
 i-nodes.
 
 If it is really your case you can disable caching, mounting nullfs
 with nocache (it looks like caching is not important in your case).
 
 -- 
 Mikolaj Golub
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org
 

Hi Goran,

After I included Kib's vnode caching patch the performance on my port builder 
machine, decreased significantly.  The port
builder is one of many jails and nullfs is used extensively. I was starving 
the system of vnodes.  Increasing the kern.maxvnodes,
resulted in better performance than the original system configuration without 
vnode caching. Thanks Kib :)

I don't think you'll run out of vnodes as it is self adjusting (that was my 
concern too)

I changed kern.maxvnode to approx 3 times what it wanted and tuned for my needs.
Try it and keep an eye on:
sysctl vfs.numvnodes vfs.wantfreevnodes vfs.freevnodes 
vm.stats.vm.v_vnodepgsout vm.stats.vm.v_vnodepgsin

Regards, Dewayne

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Nullfs leaks i-nodes

[Dewayne Geraghty]

Jeremy, 

Thank-you for your advice.  I take your point that the next time that I have an 
idea that might help, that is, suggesting that
maxvnodes should be increased and that vnode depletion vs starvation shouldn't 
be a concern;  I'll reflect on your reply for my
failure to review the vnode source and to fully understand the ramifications of 
examing the sysctl's.

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: RFC: Suggesting ZFS best practices in FreeBSD

[Dewayne Geraghty]

Jeremy,
Thank-you very much for an enlightening explanation that has changed my current 
disk naming/labelling approach. 
glabel continues to have its place with usb memory sticks.

I'd glanced at cam(4) but didn't absorb the beneficial significance.
Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Does / Is anyone maintaining CVS for FreeBSD?

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Perry Hutchison
 Sent: Friday, 4 January 2013 7:30 PM
 To: dewayne.gerag...@heuristicsystems.com.au
 Cc: erichsfreebsdl...@alogt.com; freebsd-stable@freebsd.org
 Subject: Re: Does / Is anyone maintaining CVS for FreeBSD?
 
 Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote:
 
I'm a bit reluctant to installing svn on every system 
 that needs 
source updates. Are there more lightweight ways?
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2012-Novembe
 r/070794.html
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org

Perry, Thanks for the pointer I did not consider freebsd-update as the first 
paragraph of the description only mentions binary
updates. I'll need to take a closer look.

Kimmo, I agree and usually prefer to distribute binaries as a package. However 
it includes other binaries and doc etc that aren't
required to maintain source.  The emphasise was on lightweight.  To accomplish 
the task of source maintenance (get and update) then
a static svn image is all that's required.

Erich, You're right, csup is an elegant and proven solution which I've used for 
years. We could continue using it for the life of
RELENG_9 but the change to svn becomes mandatory for 10. There has been a lot 
of discussion in this and other threads, that there is
more effort involved in maintaining sources than developers and contributors 
wish to spend when an alternative presents itself.  I'd
rather their generous contribution of time be spent of fixing or enhancing our 
OS.

The only down-side that I've noticed is that csup would replace all files 
under /usr/src which I modified (a good thing).  Svn
does not.  Where I've patched a source and there's, it needs to be told to svn 
--accept tf update /usr/src to replace a change; so
my tools can repatch.  If there's no conflict svn doesn't look at the local 
files, and the patched files are unchanged.  I'm sure
that there are better ways, but I care about svn only to the extent that I can 
maintain FreeBSD sources.

ref:
http://www.freebsd.org/cgi/man.cgi?query=freebsd-updateapropos=0sektion=0manpath=FreeBSD+9.1-RELEASEarch=defaultformat=html

Regards, Dewayne
PS I'm offsite for next 5 days so apologies in advance for delay responding.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Does / Is anyone maintaining CVS for FreeBSD?

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Erich Dollansky
 Sent: Friday, 4 January 2013 12:26 PM
 To: Patrick M. Hausen
 Cc: Eitan Adler; freebsd-stable@freebsd.org
 Subject: Re: Does / Is anyone maintaining CVS for FreeBSD?
 
 Hi,
 
 On Thu, 3 Jan 2013 18:48:01 +0100
 Patrick M. Hausen hau...@punkt.de wrote:
 
  Hello,
  
  Am 03.01.2013 um 16:36 schrieb Eitan Adler li...@eitanadler.com:
   CVS/SVN should be considered a development tool.  Users 
 should not 
   see the impact of the switch.  In theory.
  
  
  What is the recommended csup replacement for users that did
  
  cd /usr/src  make update buildworld buildkernel
  
  as their method of keeping the system current?
 
 the above's line keeps the originally installed sources 
 intact and just recompiles them again and again and again ...
  
  I'm a bit reluctant to installing svn on every system that needs 
  source updates. Are there more lightweight ways?
  
 The line above will stay the same. Only the process of 
 downloading the changes will change.
 
 Erich
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org

Erich, If there's a more lightweight way than :
1. cd /usr/ports/devel/subversion
2. turning off all options
3. turn on these options: ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC
4. make install
5. Copy the svn as needed. The image should be 4.2MB
Then I'd be happy to adopt.

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: nullfs changes MFC

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of 
 Konstantin Belousov
 Sent: Saturday, 8 December 2012 12:01 PM
 To: f...@freebsd.org
 Cc: sta...@freebsd.org
 Subject: nullfs changes MFC
 
 Hi,
 I am going to merge latest batch of the nullfs improvements 
 into stable/9. This will bring up significant performance 
 enchancements due to use of the shared locks for lookups if 
 the lower layer supports it, much better caching on the 
 nullfs layer, and proper handling of the text segments on the 
 nullfs. Also, it should improve the error recovery and some 
 corner cases with locking.
 
 Unfortunately, the merge would break KBI for VFS, since it 
 needs 5 new VOP slots, and only three spares are left. We 
 already are very liberal with the VFS KBI, so I do not feel 
 that the merge is not acceptable, due to the benefits it 
 brings to the nullfs.
 
 The merge is available at
 http://people.freebsd.org/~kib/misc/nullfs_9.1.patch


Konstantin,

Thank-you for these improvements.

I've been running this patchset on test and build servers for a few weeks and 
the systems remained stable and reliable.  

On some fairly complex jail and nullfs environments there has been an 
improvement in the order of 3 to 8% for large sequential
writes. 

Regards, Dewayne
PS I've reversed out the patches now they've migrated to RELENG_9 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: Increasing the DMESG buffer....

[Dewayne Geraghty]

+1 (RAM is neither free nor abundant.)
 
Increasing the default buffers, stack or heap use, should be carefully
considered.  There was a discussion about providing guidance/examples for
loader.conf and sysctl.conf for various anticipated uses: firewall,
workstation, servers, routers whether single/dual/multi core; perhaps this
is where calls for values other than those necessary to get a basic general
purpose machine working, should be?

We manage servers providing all of: samba, squid, dovecot, sendmail, ldap,
heimdal, apache on low-energy boxes with 1G RAM, and over 8 years FreeBSD
has proven that it has the power to serve.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: geom mirror now rebuilding on every reboot?

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Frank Reppin
 Sent: Tuesday, 7 August 2012 11:46 AM
 To: sta...@freebsd.org; curr...@freebsd.org
 Subject: Re: geom mirror now rebuilding on every reboot?
 
 by any chance...
 
 ... is this maybe related to my PR:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=170038
 
 cheers,
 Frank Reppin
 
 
 --
 43rd Law of Computing:
  Anything that can go wr
 fortune: Segmentation violation -- Core dumped 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org

Maksim, Michael,
After reading Frank's PR, would you please advise how you newfs your
devices/partitions - are you using SU+J?  
Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: clang tautology

[Dewayne Geraghty]

Good point Doug, I guess the choice between a clang 3.1 and gcc 4.2.1
world/kernel is pending a  performance profile comparison.  The performance
comparison using specific applications (ports) indicates some improvement
of gcc 4.6 over 4.2 and certainly gains when openMP is advantageous.

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: clang tautology

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Matthew Seaman
 Sent: Tuesday, 29 May 2012 5:33 PM
 To: Randy Bush
 Cc: FreeBSD Stable
 Subject: Re: clang tautology
 
 On 29/05/2012 04:47, Randy Bush wrote:
  is the clang build for releng_9 for amd64 in good enough 
 shape that i 
  can simply
csup
hack make.conf
make buildworld
make kernel
boot single
make installworld
mergemaster -cviFU
reboot
  
  as if life was normal?
 
 Pace Doug's comments on how to use mergemaster, this works 
 for me.  I run my main server compiled with clang.  However, 
 it isn't under any sort of load and I haven't done any sort 
 of performance analysis so I don't know if I'd consider clang 
 on a high performance server at the moment.
 
 Most ports compile very well using clang, but there are 
 exceptions.  Not so many though as to preclude using clang as 
 the default compiler for ports.
 
   Cheers,
 
   Matthew
 
 --
 Dr Matthew J Seaman MA, D.Phil.
 PGP: http://www.infracaninophile.co.uk/pgpkey
 
 
 

Mark Linimon is monitoring the status of ports and clang at 
http://blog.vx.sk/archives/25-FreeBSD-Compiler-Benchmark-gcc-base-vs-gcc-po
rts-vs-clang.html
Which might save you some work.

FYI: This is a little dated and predates the recently committed clang v3.1
http://blog.vx.sk/archives/25-FreeBSD-Compiler-Benchmark-gcc-base-vs-gcc-po
rts-vs-clang.html

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: clang tautology

[Dewayne Geraghty]

My apologies, I clearly didn't copy the url from the right buffer, Mark
Linimon's Ports  Clang wiki is at http://wiki.freebsd.org/PortsAndClang

Dewayne

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 8.3-PRERELEASE and ATA_CAM

[Dewayne Geraghty]

Marius, 
Perhaps this mutual exclusivity issue between ATA_CAM with atapicam and
friends, should be mentioned in UPDATING as I'm sure the same question will
recur.

Thank-you for your guidance resolving the same issue that I had in 9.0
Stable.
Regards, Dewayne.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: What is actual status of SUJ in 9-STABLE?

[Dewayne Geraghty]

Use of SU+J  use with snapshots is being addressed.  Latest update (to 9.0
Stable) was today, please refer to
http://lists.freebsd.org/pipermail/svn-src-stable-9/2012-March/001406.html

If you mean to use it in production (ie with snapshots), then it is not
advisable.
Regards, Dewayne. 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: problem: bsdlabel

[Dewayne Geraghty]

Hi Matheus,

You have two options.

Option 1. Resync the in-memory and on-disk view of the world
Identify the device from 
# usbconfig list
Then power it off and then power on. If this doesn't work then you'll need
to dd the device.

For example: 
# usbconfig list
ugen4.2: DT Mini Slim Kingston at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
# usbconfig -d 4.2 power_off
# usbconfig -d 4.2 power_on

Option 2. Clear the boot blocks 
# dd if=/dev/zero of=/dev/da0 bs=1M count=1
If this doesn't help then zero the whole device, omit the bs and count
arguments.

I'd also suggest that you assign 0xa5 to the device, by 
# fdisk -p da0  /tmp/fdisk.cf
Use a text editor to change the 0xa6 to 0xa5; then write it back to fdisk
# fdisk -f /tmp/fdisk.cf /dev/da0

Of course, the excessive option is to reboot...
Regards, Dewayne.
PS I think this question would be better placed in the FreeBSD Questions
mailing list :)

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: geli keyfiles won't load automatically at boot time

[Dewayne Geraghty]

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of 
 xenophon\+freebsd
 Sent: Wednesday, 7 March 2012 5:03 AM
 To: freebsd-stable@freebsd.org
 Subject: geli keyfiles won't load automatically at boot time
 
 Whether I boot from an unencrypted UFS partition or from a 
 CD, I cannot get the boot loader to load my geli keyfiles 
 automatically.  I always have to interrupt the boot process 
 and issue load_geli commands for each provider and its 
 corresponding keyfile.  Other settings in /boot/loader.conf 
 get read and applied correctly - kernel modules, root file 
 system specification, boot hints, etc.  Here are the relevant 
 lines from /boot/loader.conf:
 
 geom_eli_load=YES
 geli_ada0p2_keyfile0_load=YES
 geli_ada0p2_keyfile0_type=ada0p2:geli_keyfile0
 geli_ada0p2_keyfile0_file=/boot/keys/ada0p2.key

Suggest that you try 
geli_ada0p2_keyfile0_name=/boot/keys/ada0p2.key

Etc.
Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: New BSD Installer

[Dewayne Geraghty]

To answer an earlier question by Bruce... 

 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Ian Smith
 Sent: Wednesday, 15 February 2012 4:15 AM
 To: Bruce Cran
 Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov
 Subject: Re: New BSD Installer
 
 On Sun, 12 Feb 2012 15:32:51 +, Bruce Cran wrote:
   On 2/10/2012 7:47 PM, Alex Samorukov wrote:
I am highly against reverting. Old installer is not GPT 
 aware and in factis unmaintained for a very long time.
  
   That's not really correct: quite a lot of work was done on 
 it last year.
 
 Indeed.  Was it you working on the updated sade(8) adding GPT and ZFS?
 
 rant
 
 I don't see it in terms of reverting.  Much other useful 
 functionality of sysinstall has yet to be reimplemented.  
 Sure, I know, send code .. 
 but it's not only the functionality lost, but the ability for 
 new users to accomplish a good deal of initial server setup 
 before they're skilled enough to do it all from the command 
 line, which is where I was in '98.
 
 I also think much of the sometimes gratuitous deprecation of 
 sysinstall is unwarranted.  I've used sysinstall 
 post-installation regularly since
 '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2. 
  Since one small disaster on 3.3 about 12 years ago 
 (installing to the wrong slice) I've had no major issues with 
 it, mostly partitioning all sorts of disks but also browsing 
 and adding useful packages at installation.
 
 Strangely, the big push to GPT partitions was oft said to be 
 because MBR slices provided too few partitions.  I never 
 found 4 * 6 much of a limit myself, and now the default 
 install makes a Linux-like single partition, rendering dump  
 restore more or less unusable or at least impractical, while 
 booting multiple systems on GPT also seems to require Linux tools.
 
 I don't know whether this move away from BSD traditional 
 filesystem partitioning (/, /var, /usr etc) to Linux-style 
 came down from Core On High or is just the prerogative of 
 installer-writers?  Jordan was both the latter and a big part 
 of the former for many years, but I guess that's something 
 that can be reverted if people feel to do so.
 
 I expect most developers run mostly the latest gear, and 
 nowadays tend to use vbox images a good deal, but there will 
 be many laptops and other systems using MBR slices and 
 bsdlabel partitions for years to come, and I'd hate to see 
 FreeBSD's longterm support for _slightly_ older hardware 
 disappear, just because of having added better support for latest kit.
 
 I for one will be screwed if sade, fdisk and bsdlabel 
 disappear, as the release notes for 9 seem to indicate may be 
 imminently on the cards.
 
 /rant
 
 cheers, Ian
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscr...@freebsd.org

I've included the gpart commands that should allay your concerns about fdisk 
and bsdlabel. Like you I use MBR for exactly the
reasons that Freddie has articulated, and share Jeremy's concerns.  GPT doesn't 
yet suit my operations model for bootable media;
so

The following will prepare the partitions/slices for a conventional device, for 
example a small usb drive

 D=da1 SIZE=1G
 gpart create -s MBR $D  

 gpart add -b63 -s $SIZE -t freebsd $D# to insert s1
 gpart create -s bsd ${D}s1   # create s1 as BSD
 gpart add -s 300M -t freebsd-ufs ${D}s1  # create partition s1a
 gpart add -s 16M  -t freebsd-swap ${D}s1 # create swap
 gpart add -t freebsd-ufs ${D}s1  # rest to s1d

 gpart add -s $SIZE -t freebsd $D # to insert s2
 gpart create -s bsd ${D}s2 # create s2
 gpart add -s 256M -t freebsd-ufs ${D}s2  # should be s2a
 gpart add -s 16M  -t freebsd-ufs ${D}s2  # should be s2d
 gpart add -s 32M  -t freebsd-ufs ${D}s2  # should be s2e
 gpart add -s 48M  -t freebsd-ufs ${D}s2  # should be s2f
 gpart add -s 64M  -t freebsd-ufs ${D}s2  # should be s2e
 gpart add -t freebsd-ufs ${D}s2  # should be s2h

 gpart bootcode -b /boot/boot0 ${D}
 gpart bootcode -b /boot/boot ${D}s1
 gpart set -a active -i 1 ${D}  # This is redundent, but emphasises the point :)

I like the convenience of this approach as it eliminates the fiddly fdisk and 
bsdlabel work. Enjoy.

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c

[Dewayne Geraghty]

Hi Mikolaj,

As part of the process, I delete all logs, audit trails of the build, 
/usr/obj/* and the various DESTDIR's that have been set.
The build process is from a single /usr/src but I do modify MAKEOBJDIRPREFIX, 
DESTDIR and various WITHOUT_ statements through
variable switches in {make,src}.conf.

And you're right, in the sources, KERN_PROC_ENV is defined.
# ls -lrth /usr/src/sys/sys/sysctl.h
-rw-r--r--  1 root  wheel30k Jan 30 19:56 /usr/src/sys/sys/sysctl.h
# grep KERN_PROC_ENV /usr/src/sys/sys/sysctl.h
#define KERN_PROC_ENV   35  /* get environment */

The clue seems to be in here
# ls -lrth /usr/src/sys/sys/ |tail -n 12
-rw-r--r--  1 root  wheel   4.2k Jan 16 19:10 mchain.h
-rw-r--r--  1 root  wheel   8.2k Jan 16 19:10 iconv.h
-rw-r--r--  1 root  wheel   6.2k Jan 23 22:24 umtx.h
-rw-r--r--  1 root  wheel31k Jan 23 22:24 pmc.h
-rw-r--r--  1 root  wheel11k Jan 23 22:24 param.h  # The following aren't 
copied into /usr/include
-rw-r--r--  1 root  wheel30k Jan 30 06:24 mount.h
-rw-r--r--  1 root  wheel30k Jan 30 19:56 sysctl.h
-rw-r--r--  1 root  wheel   5.6k Jan 30 19:56 resourcevar.h
-rw-r--r--  1 root  wheel39k Jan 30 19:56 proc.h
-rw-r--r--  1 root  wheel15k Feb  4 15:19 mutex.h
-rw-r--r--  1 root  wheel40k Feb  4 15:19 elf_common.h
-rw-r--r--  1 root  wheel11k Feb  4 15:19 sx.h
# ls -lrth /usr/include/sys/ | tail -n 12
-r--r--r--  1 root  wheel11k Jan  9 00:05 syscallsubr.h
-r--r--r--  1 root  wheel11k Jan  9 00:05 syscall.h   
-r--r--r--  1 root  wheel   5.0k Jan  9 00:05 resource.h
-r--r--r--  1 root  wheel10k Jan  9 00:05 file.h
-r--r--r--  1 root  wheel10k Jan  9 00:05 fcntl.h
-r--r--r--  1 root  wheel   6.4k Jan 13 10:32 taskqueue.h
-r--r--r--  1 root  wheel28k Jan 14 17:54 vnode.h
-r--r--r--  1 root  wheel   8.2k Jan 16 19:38 iconv.h
-r--r--r--  1 root  wheel   4.2k Jan 16 19:38 mchain.h
-r--r--r--  1 root  wheel   6.2k Jan 23 23:09 umtx.h
-r--r--r--  1 root  wheel31k Jan 23 23:09 pmc.h
-r--r--r--  1 root  wheel11k Jan 23 23:09 param.h  # I'm looking into why 
this is the last file copied.

I'm reviewing my build logs to ascertain why files after param.h aren't being 
copied from /usr/src/sys into /usr/include

Its after midnight so I'll continue investigating tomorrow, clearly its going 
to take some time. The buildworld succeeding only
for amd64/K8-sse is the really confusing part.  So far, I note that log files 
each contain:
...
if [ -L /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys ]; then  rm -f
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys;  fi
...

cd /usr/src/include/../sys/sys;  for h in *.h; do  ln -fs ../../../sys/sys/$h
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys;  done
...
Which seems normal.  

And yes, grep KERN_PROC_ENV  
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys/sysctl.h is defined 

Kind regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: AHCI timeouts - 8.1-PRERELEASE

[Dewayne Geraghty]

Quick update.
Following extensive testing, I've recommended to Alexander, in a 
longer email, that the default for VIA's VT8251 AHCI Controller 
be set at AHCI_Q_NOPMP|AHCI_Q_NONCQ

Use of ahci in the kernel without this option will result in timeouts, 
ultimately preventing the machine from performing IO. No timeouts 
occurred when the ahci driver was removed from the kernel.

Approx 35 tests were applied, simultaneously copying a large number 
of files (~2000) to 8 partitions that ranged in size from 10B to 1.6GB.
Testing included single and gmirror disks.  

The removal of NCQ resulted in a degraded performance of  8% when 
compared against EDGEIS, which failed under gmirror testing.  
Performance under load without NCQ was better than a kernel 
without ahci.

The test was conducted on a VIA SN18000 using two WD500GB-AAKS disks, 
the disks were repartitioned (gpart) and system rebooted before each test.

Regards, Phil.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

make distribution halts during install (7.1Prerelease today)

[Dewayne Geraghty]

The make distribution phase of a full build of 7.1 Prerelease, sourced today 
(Mon Dec  1 10:34:45 UTC 2008), unfortunately failed.

make distribution DESTDIR=/differentplace 
failed (see below), however the following worked ok: buildkernel, 
installkernerl, buildworld, installworld. Two systems (a Uni and Dual 
processor) were used and both failed at the same point.  Both building systems 
were successful in building/installing kernel and world for themselves and for 
a different DESTDIR (per the Handbook).  Only the make distribution failed (a 
clue?)

The repeated attempts to make distribution DESTDIR=X failed at the same 
location (see below). The error message suggestions incorrect parameters to 
install.  Advise/guidance welcome.

#cd /usr/src  make DESTDIR=/usr/k_brfw-d distribution
cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=i386  MACHINE=i386  
CPUTYPE=  GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac 
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 make distribution
cd /usr/src/etc;  install -o root -g wheel -m 644  amd.map apmd.conf auth.conf  
crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf  ddb.conf 
dhclient.conf disktab fbtab freebsd-update.conf  ftpusers gettytab group  hosts 
hosts.allow hosts.equiv hosts.lpd  inetd.conf libalias.conf login.access 
login.conf mac.conf motd  netconfig network.subr networks newsyslog.conf 
nsswitch.conf  portsnap.conf pf.os phones profile protocols  rc rc.bsdextended 
rc.firewall rc.firewall6 rc.initdiskless  rc.sendmail rc.shutdown  rc.subr 
remote rpc services shells  snmpd.config sysctl.conf syslog.conf  etc.i386/ttys 
 /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config  
/usr/src/etc/../usr.bin/mail/misc/mail.rc  
/usr/src/etc/../usr.bin/locate/locate/locate.rc nscd.conf /usr/k_brfw-d/etc;  
cap_mkdb -l /usr/k_brfw-d/etc/login.conf;  install -o root -g wheel -m 755  
netstart pccard_ether rc.suspend rc.resume /usr/k_brfw-d/etc;  install -o root 
-g wheel -m 600 
 master.passwd nsmb.conf opieaccess /usr/k_brfw-d/etc;  pwd_mkdb -L -i -p -d 
/usr/k_brfw-d/etc  /usr/k_brfw-d/etc/master.passwd
install: wrong number or types of arguments
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
   [-o owner] file1 file2
   install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
   [-o owner] file1 ... fileN directory
   install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64

Stop in /usr/src/etc.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

I also tried various CPUTYPES to ensure that all parameters to make, were 
populated.  Having spent most of the day building kernels/worlds and 
gstripping, gjournalling and building a lot of ports, the package is looking 
pretty good.  I hope that my explanation is concise it's been a long day and 
I'm stuck.
Regards, Dewayne.


  Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now 
http://au.docs.yahoo.com/homepageset/?p1=otherp2=aup3=tagline

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make distribution halts during install (7.1Prerelease today)

[Dewayne Geraghty]

My earlier post falls into the embarrassing, wish that I hadn't category. To 
prevent anyone wasting effort, I'm replying.

make distribution DESTDIR=/newplace
requires a 
make world DESTDIR=/newplace
as a prerequisite.  

The earlier post, caused me to believe that there was an error in 
/usr/bin/install, when using:
make distribution DESTDIR=/differentplace
The granularity of my testing was inappropriate. Apologies for the distraction. 
 

Dewayne


  Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now 
http://au.docs.yahoo.com/homepageset/?p1=otherp2=aup3=tagline

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: machine hangs on occasion - correlated with ssh break-in attempts

[Dewayne Geraghty]

There are many excellent suggestions on how to deal with invalid/unauthorised 
access attempts via ssh.  I'd used sshguard for around 8 months but recently 
changed to bruteblock, both are in the ports/security.  sshguard was very easy 
to configure, via rc.conf arguments.    Bruteblock handled the same problem 
more elegantly: uses two processes one for monitoring audit.log, via a pipe and 
one for maintaining the ipfw table entries, it uses the ipfw table value with 
the date/time entered, and the C code is cleaner (some optimisations are 
possible but this is V0.5).  

If you'd like to try it here are the steps I used to get it going:


Install package


Configure /usr/local/etc/bruteblock-ssh.conf (Using regexp
from sample, but modify parameters to suite your environment.)

regexp  =
sshd.*Illegal user \S+ from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

regexp1 =
sshd.*Failed password for (?:illegal user )?\S+ from
(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}

# three failures in 3 minutes is blocked for a day, using ipfw2 table 
10max_count   = 3

within_time = 180

reset_ip    = 86400

ipfw2_table_no = 10

 

Insert into /etc/syslog.conf

auth.info;authpriv.info |exec /usr/local/sbin/bruteblock –f 
/usr/local/etc/bruteblock-ssh.conf
Add to firewall rules (and /etc/rc.firewall)ipfw add 4 deny ip from table\(10\) 
to any
ipfw add 4 deny ip from any to table\(10\) Add into 
/etc/rc.confbruteblockd_enable=YES
bruteblockd_table=10
bruteblockd_flags=-s 7200  # How frequently to review the ipfw table for 
entry removal Now restart syslog, and start bruteblockd/etc/rc.d/syslogd restart
/usr/local/etc/rc.d/bruteblockd.sh start



  Win a MacBook Air or iPod touch with Yahoo!7. 
http://au.docs..yahoo.com/homepageset
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: broken re(4)

[Dewayne Geraghty]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gerrit Kühn
Sent: Thursday, 29 May 2008 7:58 PM
To: Gerrit Kühn
Cc: [EMAIL PROTECTED]; freebsd-stable@freebsd.org
Subject: Re: broken re(4)

On Wed, 28 May 2008 17:56:10 +0200 Gerrit Kühn [EMAIL PROTECTED]
wrote about Re: broken re(4):

GK PY http://people.freebsd.org/~yongari/re/re.HEAD.20080519
.
GK Somehow the two interfaces seem to interfer with each other. Can I 
GK provide further information for fixing this?

Meanwhile I booted the machine with the patch several times. I get either
the same status as without the patch (both interfaces basically working, but
with hangs and checksum errors under load) or I get one interface working
fine and one not working at all.
I tried turning one if off in the bios, but this didn't change the
situation: The remaining one is either working with problems or not at all.

Can I do anything else? Is the newer patch (from yesterday) in your
directory above worth giving a try?


cu
  Gerrit

--- Reply ---
You might try, after rebooting, to physically unplug and replug your
networking cables.

I have a few EN-15000 and SN-18000 motherboards attached to different types
of switches. With the SN-18000 on FreeBSD 7.0R-p1 to make the vge NIC
function even after rebooting I need to unplug the NIC's. Doesn't matter
what switch, or even using a crossover cable, the card needs to reinitialise
itself.  This may be similar the problem that you're experiencing.  And as
Pyon YongHyeon mentions there is a lot of variety with rl and re cards, I
also use re in my ITX motherboards, without experiencing your issues.

Also, after rebooting your machines try performing tcpdump -vv on the
interface that isn't working while (ie before  after) you try the
unplug/plug sequence.  (vge's since 6.1R experience a lot of incorrect
checksums.)  I'm suggesting these steps as they might also assist others
with clues to assist diagnoses with your re's)
Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Install of 6.3RC1 on Virtual PC 2007 hangs

[Dewayne Geraghty]

The installation of 6.3RC1 hangs at the line
Trying to mount root from ufs:/dev/md0
 
the probes immediately before this were:
md0: Preloaded image /boot/mfsroot 4423680 bytes at 0xc0b47cd4
ad0: 8195MB Virtual HD 1.1 at ata0-master WDM2
acd0: DVDROM Virtual CD/ at ata1-master PIO4
 
This is being attempted via Virtual PC 2007 on a Core2Duo T5500 with 256MB
allocated to the image, and 8GB to the VDisk.  The physical CD has been used
to successfully install on standalone computers, so the burnt image is ok.
 
This isn't urgent but should be noted as there may be other virtualisation
instances where RC1 doesn't install as expected.  We're happy to perform
other tests as required.  We're staging 6.3 on Via C7's, and Intel with
hifn's, and the notebook is used for quick testing of crash/burn work.
 
Regards, Phil.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: IPSEC + Via Padlock + racoon + Windows

[Dewayne Geraghty]

My apologies for the confusion, yes, the C7 only helps with AES.  

The configuration detail is: between branch offices I use FreeBSD ipsec
(AES), and within the branches Windows boxes access the firewall boxes.  The
firewalls run samba inside a jail. Due to sensitive information (see your
local Privacy legislation), we also need to encrypt the information between
samba jail and the PC-WXP devices. Hence the need to use ipsec-AES on the
WAN and ipsec-3des on the LAN (as 3des is the best option selectable for
WXP). 

Regards, Dewayne.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

IPSEC + Via Padlock + racoon + Windows

[Dewayne Geraghty]

We're looking to deploy FreeBSD on our main firewall.  The firewall config
is a VIA C7 (padlock), racoon(ipsec-tools-0.7), IPSec.  We're testing racoon
with a windows box, however the firewall doesn't function correctly when
net.inet.ipsec.crypto_support=1 is set.  With a
net.inet.ipsec.crypto_support=0 it does.  

The firewall was configured with FreeBSD 6.2R and replaced with 6.3RC1 on a
separate HDD (as at 2007-12-02).

Doesn't function correctly means that after phase 1  2 negotiation the
Windows box is able to send a ping (from WXP-SP2+) to the server.  The
server doesn't respond to the pings, but generates pfkey Update failed
messages during racoon debugging.  (wireshark was running on the PC-WXP,
tcpdump on FreeBSD)

The testing was performed with both ends configured for esp transport mode,
3des and md5 for encryption and hashing, and pfs (diffe-helman 2 (1024)).
These two machines were connected on a stand-alone network (via crossover
cables).

Server kernel uses
options FAST_IPSEC
device  cryptodev
device  padlock
options IPFIREWALL

/etc/sysctl.conf contains the following which may be relevant:
net.inet.ip.fastforwarding=1  
kern.cryptodevallowsoft=1
net.inet.ipsec.crypto_support=1# this was toggled 1/0 during testing
net.inet.icmp.icmplim=10   # These may be off-track?
net.inet.tcp.slowstart_flightsize=4  

I hope that someone can provide some guidance, as I'm looking forward to
getting the performance out of these energy efficient little processors.  I
should note that IPSec works fine between FreeBSD boxes with
net.inet.ipsec.crypto_support=1 however we have to reconfigure for
high-value PC communications.  I'd like to have my cake
(freebsd-ipsec-padlock) and eat it too (WXP) ;)

Reference: 
net.inet.ipsec.crypto_support values from
(http://groups.google.ca/group/mailing.freebsd.stable/browse_frm/thread/f3f1
40e615d9ca62/31935038340cc323?lnk=stq=fast_ipsec+net.inet.ipsec.crypto_supp
ortrnum=5hl=en#31935038340cc323 )

Dewayne (Phil) Geraghty

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

P4 (4.10) kernel build performance with/without SMP/APIC_IO/hyperthreading

[Dewayne Geraghty]

Re an earlier em thread, HTTP and SMP April 2004, I
decided to test my out-of-the-box P4 (2.8E) HT
threading enabled with SATA HD.

Test was to build identical kernels using FreeBSD 4.10
taking note of the compile times. Then reboot with:
SMP, APIC_IO in kernel, and machdep.hlt_logical_cpus:
0.  In all cases CPU_ENABLE_SSE was also enabled.

Summary for two clean kernel builds, using csh time
---
Kernel build without SMP, APIC_IO, (no variable 
machdep.hlt_logical_cpus)
1) 143.612u 23.095s 2:52.19 96.8%  1487+2195k
1872+2748io 0pf+0w
2) 143.831u 22.830s 2:55.61 94.9%  1488+2194k
3249+2747io 130pf+0w

Kernel build with SMP, APIC_IO,
machdep.hlt_logical_cpus=0
3) 145.106u 33.345s 2:57.38 100.5% 1451+2093k
3205+2746io 128pf+0w
4) 146.284u 32.481s 2:50.61 104.7% 1446+2093k
207+2745io 0pf+0w

An interesting result - the run (3) time was
reproduced and revealed that files were being deleted
via softupdate, and should be discarded. Experimental
error on my part.  This didn't affect runs 1  2.

I repeated run 4 redirecting io to a file to reduce
screen delays, but with little difference.
# cd ..; rm -R TEST3; cd /sys/i386/conf; config TEST3;
cd ../../compile/TEST3; 
# time make depend all /tmp/build.lis
146.155u 32.623s 2:50.59 104.7% 1447+2090k 185+2755io
0pf+0w

In this test of kernel builds, you'll save around 1.1%
of your time using SMP with logical HT CPU's on
FreeBSd 4.10.  

Regards, Dewayne.

PS: Of course I attempted to make -j2 depend all but
this failed as a previous module hadn't completed when
needed. e.g. bioscall.s


Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]