Re: PAM modules; pthreads not reliably dispatching background threads :(.

[Jan Bramkamp]

On 09.02.20 12:25, Dr Josef Karthauser wrote:

Hi Folks,

Has anyone got any experience with PAM and pthreads?

We’re using a 2FA module (pam_yubico 
https://www.freebsd.org/cgi/man.cgi?query=pam_yubico=8 
).

It’s proving unreliable. Digging deeper it uses libcurl to communication to an 
HTTP endpoint, and libcurl is using pthreads for to make asynchronous DNS 
lookup requests.

It seems that the pthreads are not being handled reliably within the PAM 
runtime context - the background threads do not complete or dispatch. It’s very 
strange.

The problem doesn’t happen if we use the same code running from a user land 
process. The pthreads are reliably in this context.

Is there a known issue with PAM and pthreads? Hints are that there are 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214540 
). But that problem 
was reported 3 years ago!

HELP!

If you know something I’d really appreciate a steer!

Is the "host" process multithreaded or at least built with Pthread support?
___
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: No amdtemp sysctls, AMD Ryzen 5 3600X

[Jan Bramkamp]

Here is the patch to add support for 3rd gen Ryzen to amdtemp:

Index: sys/dev/amdsmn/amdsmn.c
===
--- sys/dev/amdsmn/amdsmn.c    (revision 355171)
+++ sys/dev/amdsmn/amdsmn.c    (working copy)
@@ -59,6 +59,7 @@
 #define    PCI_DEVICE_ID_AMD_15H_M60H_ROOT        0x1576
 #define    PCI_DEVICE_ID_AMD_17H_ROOT        0x1450
 #define    PCI_DEVICE_ID_AMD_17H_M10H_ROOT        0x15d0
+#define    PCI_DEVICE_ID_AMD_17H_M30H_ROOT        0x1480

 struct pciid;
 struct amdsmn_softc {
@@ -90,6 +91,12 @@
     .amdsmn_addr_reg = F17H_SMN_ADDR_REG,
     .amdsmn_data_reg = F17H_SMN_DATA_REG,
 },
+    {
+        .amdsmn_vendorid = CPU_VENDOR_AMD,
+        .amdsmn_deviceid = PCI_DEVICE_ID_AMD_17H_M30H_ROOT,
+        .amdsmn_addr_reg = F17H_SMN_ADDR_REG,
+        .amdsmn_data_reg = F17H_SMN_DATA_REG,
+    },
 };

 /*
Index: sys/dev/amdtemp/amdtemp.c
===
--- sys/dev/amdtemp/amdtemp.c    (revision 355171)
+++ sys/dev/amdtemp/amdtemp.c    (working copy)
@@ -96,6 +96,7 @@
 #define    DEVICEID_AMD_MISC16_M30H    0x1583
 #define    DEVICEID_AMD_HOSTB17H_ROOT    0x1450
 #define    DEVICEID_AMD_HOSTB17H_M10H_ROOT    0x15d0
+#define    DEVICEID_AMD_HOSTB17H_M30H_ROOT    0x1480

 static const struct amdtemp_product {
 uint16_t    amdtemp_vendorid;
@@ -118,6 +119,7 @@
 { VENDORID_AMD,    DEVICEID_AMD_MISC16_M30H, true },
 { VENDORID_AMD,    DEVICEID_AMD_HOSTB17H_ROOT, false },
 { VENDORID_AMD,    DEVICEID_AMD_HOSTB17H_M10H_ROOT, false },
+    { VENDORID_AMD,    DEVICEID_AMD_HOSTB17H_M30H_ROOT, false },
 };

 /*

On 15.11.19 15:07, Mark Martinec wrote:

On 15/11/2019 3:27 am, Mark Martinec wrote:

Running 12.1-RELEASE-p1 on AMD Ryzen 5 3600X cpu,
but I don't see any temperatures reported in sysctl,
even though amdtemp.ko and amdsmn.ko are loaded
and they don't produce any complaints on loading.


2019-11-15 03:01, Kubilay Kocak wrote:

Resolver of original Ryzen 2 temperature support:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218264
"In Progress" issue for Ryzen 5 support with patch:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239607


I have applied the patch from Bug 239607 and it works now!
Perfect, thanks!


Was committed to head (CURRENT), apparently merged to stable/12
(cant find the MFC commit).
I've updated/retriaged the issue, and asked about a merge to
stable/11, but at this point it looks like it missed the 12.1-RELEASE
window


It's unfortunate that it missed the 12.1-RELEASE.
Thanks for a quick response!

  Mark
___
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: GENERIC crash 11.3-PRERELEASE (i386)

[Jan Bramkamp]

This list doesn't allow attachments.

Diese Mailingliste erlaubt keine Anhänge.

On 26.06.19 10:13, Schuendehuette, Matthias wrote:

Hello,

for some days now the GENERIC kernel of 11.3-PRERELEASE (i386) crashes on my
ProLiant DL380 G5 server.

Main error message is "kernel trap 12 with interrupts disabled".

Since there is no crash dump I attach some screen shots of the boot messages.
I hope this does not violate the mailing list rules...

The GENERIC config-file is:
# $FreeBSD: stable/11/sys/i386/conf/GENERIC 323770 2017-09-19 16:51:51Z 
jpaetzel $

The last working kernel I have is from June 5, 2019.

As always: If additional information is needed, I'll do whatever is necessary. 
:-)


with best regards

Matthias Schündehütte

Siemens AG
Large Drives Applications
Information Technology
Information Technology Product Lifecycle Management
LDA IT PLM
Nonnendammallee 72
13629 Berlin, Deutschland

mailto:matthias.schuendehue...@siemens.com

___
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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE

[Jan Bramkamp]

On 28.02.18 18:03, Hadi Rezaee wrote:

Hello there,
My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my 
graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But 
now it getting failed. Tried to build from source, but same result.

Laptop model: Lenovo E470


I just updated both the 12-current base system and the 
graphics/drm-next-kmod port on my Thinkpad T470s. The resulting system 
works except for the already documented regression in the VA API 
affecting hardware accelerated video playback in mpv.

___
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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE

[Jan Bramkamp]

On 25.02.18 16:48, Johannes M Dieterich wrote:

Dear all,

Please CC me as I am not subscribed.

On behalf of the FreeBSDDesktop team and thanks to the tireless efforts
of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to
report that the graphics/drm-next-kmod port just received an update to
Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent
CURRENT and 11-STABLE.

We have tested this on a range of hardware ourselves:
* Haswell
* Broadwell
* Skylake
* Evergreen
* Kaveri (both radeon and amgpu KMS)
* Carrizo
* Polaris

Needless to say, the possible space of hardware this could run on is
significantly larger. Hence, if you find issues and/or want to propose
patches, please do so at our development github:

https://github.com/FreeBSDDesktop/kms-drm

We absolutely do welcome contributions!

Johannes


Thx for your hard work. The drm-next-kmod port enabled me to finally 
replace my ageing Thinkpad X220 with newer hardware.


The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod 
port introduced a regression which causes Xorg on my T470s running 
12-current from a few days ago to fail at startup stating that it didn't 
find any screen.

___
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: Boot partition size

[Jan Bramkamp]

On 29/01/2017 06:43, Aristedes Maniatis wrote:

On 29/1/17 3:50pm, Warner Losh wrote:

 (2) shrinking a swap partition to snag
some space

Yes, except I put my swap into a zvol. I did this when I lost a disk once with 
a dedicated swap partition and that caused the system to crash. So I realised 
that dedicated swap was a really bad idea and I needed to choose between zvol 
and gmirror. I chose zvol to avoid having one more thing to check and worry 
about.


Swapping to ZVOLs is dangerous. Writes to a ZVOL may require kernel 
memory allocations to finish. This can deadlock/panic your system if the 
write was to a swap device. I would recommend using GEOM mirror for swap 
devices.

___
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: buildworld build times 10-stable vs. 11-stable

[Jan Bramkamp]

On 15/01/2017 17:40, Dan Mack wrote:

I have a system which builds world, kernel, install, boot, installworld,
reboot several times per week.   I just noticed that my build times
increased from about (just cherry picking a couple build logs):

  Starting build of FreeBSD SVN [309852]  10.3-STABLE
  Kernel will be GENERIC
building world ... 90:35 0


  Starting build of FreeBSD SVN [312099]  11.0-STABLE
  Kernel will be GENERIC
building world ... 146:23 0

before I start bisecting the log files, is there something obvious
introduced in 11 that I missed that would explain the roughly 50 minute
difference in my build times?   clang?  additional subsystems?

I'm using the same zpool / disks / memory etc.


If you're compiling often enough for this to be an issue use the new 
bmake meta mode. In meta mode make keeps metadata gathered by the kernel 
and exported to make over filemon(4) around. With this a `make -sj4 
buildworld buildkernel` after a small change (e.g. next patch) takes 
less than 3 minutes on my old SandyBridge dual-core ThinkPad X220 with 
cold file system caches. To enable it run `echo WITH_META_MODE=yes 
>/etc/src-env.conf`, instruct the kld rc.d script to load filemon with 
`sysrc kld_list+=" filemon"` and use the rc.d script to load the kernel 
module with `service kld start` (or reboot).


The next buildworld and buildkernel will store the metadata in /usr/obj. 
Any builds of similar versions after that will have drastically shorter 
build times.


This optimization is available starting with FreeBSD 11.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: Help! two machines ran out of swap and corrupted their zpools!

[Jan Bramkamp]

On 21/11/2016 18:47, Pete French wrote:

So, I am off sick and my colleagues decided to load test our set of five
servers excesively. All ran out of swap. So far so irritating, but whats has
happened is that twoof them now will not boot, as it appears the ZFS pool
they are booting from has become corrupted.

One starts to boot, then crases importing the root pool. The other doenst
even get that far with gptzfsboot saying it can't find the pool to boot from!

Now I can recover these, but I am a bit worried, that it got like this at
all, as I havent ever seen ZFS corrupt a pool like this. Anyone got any 
insights,
or suggstions as to how to stop it happening again ?

We are swapping to a separate partition, not to the pool by theway.


How much trust do you put in your hardware? Have you ever put the 
hardware under full load for extended periods before e.g. run poudriere 
to build pkg repos?


-- Jan Bramkamp
___
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: vt console driver and default vga mode: breaking POLA

[Jan Bramkamp]

On 09/09/16 11:59, Borja Marcos wrote:


Hi

I apologise for being late on this, but I just noticed. The new vt console 
driver has a very important
change in behavior, replacing the ancient “BIOS” text mode with a graphic VGA 
mode.

I don’t know how many people relies on BIOS serial redirection for consoles, 
but at least
HP’s iLO system offers the possibility of accessing the console through a ssh 
connection instead
of requiring a bloated Java console, and it’s a very convenient feature. But it 
only works in pure
“BIOS text mode” (the old sc console driver used this mode as a default).

I would rather change the default behavior of vt to hw.vga.textmode=1 so that 
its behavior mimics
the old sc driver.

I know the current fad is to hide boot messages with panda bears and beautiful 
butterflies revolving
around them, but boot messages are critical when diagnosing problems.

I should have chimed in earlier, I know. But anyway it’s a very minor change.




What do you think?


The presence of a ipmi* device could be a good heuristic to select the 
default mode.

___
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 10.3 slow boot on Supermicro X11SSW-F

[Jan Bramkamp]

On 28/06/16 15:59, Miroslav Lachman wrote:

I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It
sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2.

The booting is painfully slow from BTX to menu to kernel loading.
Progress indicated by \ | / - characters is changing by speed of 1
character per 2 seconds.
The whole boot process takes about 10 minutes.

I found this blog post solving the same problem
http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/

It seems there is some bug in loader in 10.3. If /boot/pmbr,
/boot/gptzfsboot and /boot/zfsloader are replaced by files from
11-CURRENT snapshot (from
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/11.0-CURRENT/base.txz)
the booting speed is back to normal.

Is it know problem? What was changed in loader between 10.3 and 11?


The bootloader disk caching. The old code doesn't work (well) on modern 
UEFI implementations. You can get acceptable bootloader performance with 
the FreeBSD 10.3 EFI bootloader on such boards. Even the UEFI install 
images contain fallback BIOS bootcode and some boards prefer the old 
BIOS bootcode. On such boards you have to suffer through the slow boot 
process once to install FreeBSD.

___
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: Best practices for ZFS setup for a strictly SSD based system?

[Jan Bramkamp]

On 09/02/16 16:54, Patrick M. Hausen wrote:

Hi, all,

while there is quite a bit of documentation on how to improve ZFS performance
by using a combination of rotating disks and SSDs, I have not found much about
an SSD only setup.

We are planning to try a hosting server with 8 SATA SSDs with ZFS. Things I am
not at all sure about:

*   Does the recommended limit of 6 disks for a RAIDZ2 still
hold? 2x 4 disks is quite a bit of overhead, could I use all 8
in one vdev and get away with it?
(The maximum of 6 recommendation is in some old Sun doc)


There are multiple reasons to limit number of disks per RAID-Z VDEV.

 * Resilver time: ZFS has to process all objects ordered by transaction 
id to resilver a RAID-Z. Resilvering is a torture test for the remaining 
disks of your degraded RAID-Z and with the ratio of bandwidth to 
capacity of current hard disks resilvering takes too long. This isn't an 
issue for SSDs.


 * For performance estimations think of the RAID-Z of one huge disk 
with larger blocks but the same IOPS as the slowest disk in the RAID-Z. 
Databases perform disk I/O in small blocks limiting your RAID-Z to the 
performance of about one of its member disks.


 * A ZFS pool can only grow by adding whole VDEVS or replacing all 
disks in a VDEV one at a time. Using mirror allows the pool to grow in 
smaller increments.



*   Will e.g. MySQL still profit from residing on a mirror
instead of a RAIDZ2, even if all disks are SSDs?


Yes OpenZFS schedules reads on mirrors to the disk with the shortest 
queue thus a mirror offers about sum of its member disks in read 
performance (IOPS and bandwidth) and the minimum of its member disks in 
write performance (IOPS and bandwidth). A pool with as many mirrored 
VDEVs as possible will offer the optimal performance for a given number 
of disks. For write heavy workloads the quality of the SSDs matters a 
lot as well. Cheap consumer SSDs can't sustain high write rates for any 
length of time. Even medium quality SSDs have a lot of jitter and suffer 
from throughput degradation under sustained write loads. Optimized 
server SSDs can sustain random write workloads with little jitter and 
bounded latency.


A NVMe SSD can offer an additional order of magnitude performance 
increase over SATA SSDs but at a significant increase in price. With 
multiple NVMe SSDs you will run into the current scalability limits of 
ZFS and GEOM.



*   Does a separate ZIL and/or ARC cache device still
make sense?


Most likely not.



An other optimization is splitting the log and table space and creating 
a dedicated ZFS dataset for each. Create the dataset containing the 
table space with the fixed record size of your MySQL backend. ZFS also 
offers a lot more consistency and atomicity quarantines  than required 
by a minimal POSIX file system. This allows you to further reduce the 
syncing overhead by tuning MySQL to take advantage of ZFS quarantines.

___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Jan Bramkamp]

On 09/12/15 01:04, Michael B. Eichorn wrote:

On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:

I suspect this is a zfs bug that is triggered by the access patterns
in the periodic scripts. There is significant load on the system when
the scheduled processes start, because all jails execute the same
scripts at the same time.

I've been able to alleviate this problem by disabling the security
scans within the jails, but leave it enabled on the root host.


To avoid the problem of jails all starting things at the same time, use
the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
sleep for a random period of specified duration (60 sec max). Cron
flags can be set using the rc.conf variable 'cron_flags'.


While jitter would reduce the resource contention a thundering herd of 
cronjobs shouldn't cause the kernel to divide by zero. Spreading the 
load by introducing jitter to cronjobs might hide the problem, but it 
still needs further analysis.


@Dustin Wenz: Can you reproduce the problem and file a PR to track this?
___
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: Periodic jobs triggering panics in 10.1 and 10.2

[Jan Bramkamp]

On 09/12/15 13:45, Michelle Sullivan wrote:

Michael B. Eichorn wrote:

On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote:


I suspect this is a zfs bug that is triggered by the access patterns
in the periodic scripts. There is significant load on the system when
the scheduled processes start, because all jails execute the same
scripts at the same time.

I've been able to alleviate this problem by disabling the security
scans within the jails, but leave it enabled on the root host.



To avoid the problem of jails all starting things at the same time, use
the cron(8) flags -j and -J to set a 'jitter' which will cause cron to
sleep for a random period of specified duration (60 sec max). Cron
flags can be set using the rc.conf variable 'cron_flags'.
___



No that will just hide it (if successful at all) and it won't work in
all cases.

... i386 is even worse for similar (not the same) instability triggered
by the same scripts ... because zfs should not be used with the stock
i386 kernel (which means if you're using it the whole patching process
with freebsd-update won't work or will 'undo' your kernel config.)


Do you have a good idea how to prevent users from shooting themselves in 
the foot by running ZFS on 32 Bit kernels?



Personally I think zfs should be optional only for 'advanced' users and
come with a whole host of warnings about what it is not suitable for
however, it seems to be treated as a magic bullet for data corruption
issues yet all I have seen is an ever growing list of where it causes
problems.. when did UFS become an unreliable FS that is susceptible to
chronic data corruption?


As storage capacity grew a lot faster than reliability.

UFS is a good file system for its time, but it trusts hardware 
absolutely. Modern hardware doesn't deserve this level of trust. ZFS 
detects and recovers without dataloss from most errors caused by the 
limited hardware reliability.


ZFS isn't just a tool to deal with hardware limitations it's also a 
convenience I no longer want to give up. Snapshots and replication 
streams simplify backups and a background scrub once a week (or month) 
sure beats waiting for fsck.

___
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: GPU suggestion: gtx 750ti

[Jan Bramkamp]

On 04/09/15 16:34, Dot Yet wrote:

Hello,

I currently run haswell based desktop and am planning to add a second gpu
to get decent graphics functional. I am thinking about purchasing nvidia
gtx 750ti. can anyone confirm if its supported by drivers and is capable of
hardware acceleration? if not, what current day gpu should i look for? I am
not a gamer, but I do like watching 1080p movies/trailers etc.

Please let me know.


Yes a Nvidia GTX 750ti is supported by the closed source binary driver 
according to https://www.nvidia.com/download/index.aspx (enter your data 
and you end up at 
https://www.nvidia.com/download/driverResults.aspx/90283/en-us).


A GTX 750ti is a bit overpowered for light desktop and media usage but 
based on a dated microarchitecture and lacks hardware support for the 
upcoming h.265 video codec.


Nvidia drops support for old hardware in their driver from time to time 
and newer chips have a lower idle power consumption for a given peak 
performance so you might want to look for a GPU with a newer 
microarchitecture. The GTX950 would be a good fit but the nvidia driver 
port is not yet up to version 352.41 which adds support for the GTX950.

___
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: LDAP authentication confusion

[Jan Bramkamp]

On 15.07.2013 21:09, Daniel Eischen wrote: On Mon, 15 Jul 2013, Michael
Loftis wrote:

 nss_ldap fulfills most of the get*ent calls, thus based on the bits of
 your configuration you've exposed I think you're ending up with that
 behavior and not using pam_ldap at all.  Instead the authentication is
 happening via nsswitch fulfilling getpwent() call's (the passwd: files
 ldap line in nsswitch.conf)

 Ok, thanks.  But shouldn't the documentation be changed
 to reflect that?

More than that. In my opinion it should be updated by replacing nss_ldap
and pam_ldap with nss-pam-ldapd which splits the job of both into a
shared daemon talking to the LDAP server and small stubs linked into the
NSS / PAM using process talking to the local daemon. This allows useable
timeout handling and client certificates with save permissions.
___
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: LDAP authentication confusion

[Jan Bramkamp]

On 15.07.2013 21:25, Mark Felder wrote: On Mon, Jul 15, 2013, at 14:19,
Jan Bramkamp wrote:

 More than that. In my opinion it should be updated by replacing nss_ldap
 and pam_ldap with nss-pam-ldapd which splits the job of both into a
 shared daemon talking to the LDAP server and small stubs linked into the
 NSS / PAM using process talking to the local daemon. This allows useable
 timeout handling and client certificates with save permissions.


 And if the daemon ever crashes, we can't login to our customer servers
 (assuming they nuked our local account because they have root access).

 That's the one issue I have with that daemon and why we haven't migrated
 to it. We should re-evaluate it, though.

In that case run nslcd in foreground with some kind of watchdog. Their
are several examples of this in the ports tree e.g. daemontools. So far
i never ran into this problem because nslcd on any of my production
systems. I prefer nss-pam-ldapd over nss_ldap + pam_ldap because:
- It doesn't link libldap, liblber, libsasl, libssl etc. into nearly
every process.
- It keeps the LDAP connection open reducing the latency (important with
DHE-RSA ciphersuites).
- It handles timeouts in one place instead of timing out in every process.

This doesn't change the fact that the nslcd daemon is a single point of
failure for all LDAP accesses over NSS and PAM.
___
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: LDAP authentication confusion

[Jan Bramkamp]

On 15.07.2013 21:44, Daniel Eischen wrote:
 On Mon, 15 Jul 2013, Jan Bramkamp wrote:
 
 On 15.07.2013 21:09, Daniel Eischen wrote: On Mon, 15 Jul 2013, Michael
 Loftis wrote:

 nss_ldap fulfills most of the get*ent calls, thus based on the bits of
 your configuration you've exposed I think you're ending up with that
 behavior and not using pam_ldap at all.  Instead the authentication is
 happening via nsswitch fulfilling getpwent() call's (the passwd: files
 ldap line in nsswitch.conf)

 Ok, thanks.  But shouldn't the documentation be changed
 to reflect that?

 More than that. In my opinion it should be updated by replacing nss_ldap
 and pam_ldap with nss-pam-ldapd which splits the job of both into a
 shared daemon talking to the LDAP server and small stubs linked into the
 NSS / PAM using process talking to the local daemon. This allows useable
 timeout handling and client certificates with save permissions.
 
 I tried nss-pam-ldapd and it doesn't work for me.  I'm not
 doing anything strange, as you can see by my configuration.
 It would try to talk to the LDAP server, but would fail.
 I'm not sure it was correctly picking up the proxyagent
 password in my /usr/local/etc/nslcd.conf.  It was definitely
 parsing it though, as that is where the LDAP server is
 defined.  I switched to using pam_ldap and nss_ldap, and
 it worked without any problem.
 

This is my basic nscld.conf:

uid nslcd
gid nslcd

# fail over to auth2 if required
uri ldap://auth1.example.org
uri ldap://auth2.example.org

base dc=example,dc=org

scope sub

basegroup   ou=groups,dc=example,dc=org
basepasswd  ou=users,dc=example,dc=org
scope   group   onelevel
scope   hosts   sub

filter group (|(objectClass=posixGroup)(objectClass=posixGroupOfNames))
# allow groups of DNs

bind_timelimit  15
timelimit   5
idle_timelimit  3600

ssl start_tls
tls_reqcert hard
tls_cacertdir   /usr/local/etc/openldap/ca
tls_cacertfile  /usr/local/etc/openldap/ca/ca-cert.pem
tls_ciphers DHE-RSA-AES256-GCM-SHA384 # requires OpenSSL from ports
use DHE-RSA-AES256-SHA otherwise
tls_cert/usr/local/etc/nslcd.crt
tls_key /usr/local/etc/nslcd.key

sasl_mech   EXTERNAL
sasl_realm  EXAMPLE.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

Re: LDAP authentication confusion

[Jan Bramkamp]

On 15.07.2013 21:51, Daniel Eischen wrote:
 
 Wouldn't it be easier just to edit /etc/nsswitch.conf
 anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access control.

With ldap in nsswitch.conf for users and groups you can lookup a LDAP
user but the user can't log into $service through PAM. This requires
pam_ldap.so in pam.d/$service.
___
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: LDAP authentication confusion

[Jan Bramkamp]

On 16.07.2013 00:47, Ben Morrow wrote:
 Quoth Jan Bramkamp cr...@rlwinm.de:
 On 15.07.2013 21:51, Daniel Eischen wrote:

 Wouldn't it be easier just to edit /etc/nsswitch.conf
 anyway?
 PAM and NSS switch are two different subsystems. NSS is just for
 resource lookups (users, groups, hosts, ...). PAM is for access control.

 With ldap in nsswitch.conf for users and groups you can lookup a LDAP
 user but the user can't log into $service through PAM. This requires
 pam_ldap.so in pam.d/$service.
 
 The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable
 passwords in its result I think pam_unix can authenticate against those.
 
 This is not the same as authenticating by LDAP bind, but may end up
 accepting the same passwords.

If you want every process to read your hashed passwords and you use
non-portable crypt hashes it could work. The correct solution would be
authenticate users by LDAP binds without allowing anyone to read the
password or to use the {SASL} password style and authenticate users
against Kerberos with saslauthd. Just don't let you users play with
passwords. Either your password policy allows dumb users to pick trivial
password or it forces complex password structures on them resulting in
post-it notes with passwords around every second desk.
___
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: LDAP authentication confusion

[Jan Bramkamp]

On 16.07.2013 04:28, Daniel Eischen wrote:
 On Tue, 16 Jul 2013, Jan Bramkamp wrote:
 
 On 16.07.2013 00:47, Ben Morrow wrote:
 Quoth Jan Bramkamp cr...@rlwinm.de:
 On 15.07.2013 21:51, Daniel Eischen wrote:

 Wouldn't it be easier just to edit /etc/nsswitch.conf
 anyway?
 PAM and NSS switch are two different subsystems. NSS is just for
 resource lookups (users, groups, hosts, ...). PAM is for access
 control.

 With ldap in nsswitch.conf for users and groups you can lookup a LDAP
 user but the user can't log into $service through PAM. This requires
 pam_ldap.so in pam.d/$service.

 The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable
 passwords in its result I think pam_unix can authenticate against those.

 This is not the same as authenticating by LDAP bind, but may end up
 accepting the same passwords.

 If you want every process to read your hashed passwords and you use
 non-portable crypt hashes it could work. The correct solution would be
 authenticate users by LDAP binds without allowing anyone to read the
 password or to use the {SASL} password style and authenticate users
 against Kerberos with saslauthd. Just don't let you users play with
 passwords. Either your password policy allows dumb users to pick trivial
 password or it forces complex password structures on them resulting in
 post-it notes with passwords around every second desk.
 
 I think something is lost on me here.  getpwent/getpwuid do
 not return the password hashes in the returned struct passwd
 unless the calling process is root.  So you have to be root in
 order to see the hashes anyway.  Not all users are going to
 have access to the hashes, unless your machine's compromised
 or otherwise allows root privileges to others.
 
If the crypted password can be read by an LDAP client with the
information available to every process in (nss_)ldap.conf you're crypted
passwords are easily accessible for offline attacks. Their is no reason
for an attacker to go through the getpwent/getpwuid API.
___
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