Re: pppd incomatible with libradcli4
Hello, 20.10.2018 20:48, Eugene M. Zheganin пишет: Hello, I'm trying to set up the VPN stack using xl2tpd/strongswan on recent Debian 9.5, and so far everything is working except radius authentication (I have a freeradius3 setup which is fully working, so I need to use it to authenticate users). Seems like pppd is totally incompatible with libradcli4: when I add plugin radius.so plugin radattr.so into the /etc/ppp/options.xl2tpd configuration file, pppd starts complaining about missing directives: first, /etc/radiusclient/radiusclient.conf cannot be read. Okay, I don't know if it's right, but since radiusclient1 seems to be vanished completely, I can link /etc/radcli as /etc/radiusclient. Then the following happens: /etc/radiusclient/radiusclient.conf: mapfile not specified /etc/radiusclient/radiusclient.conf: seqfile not specified These two can be easily (again, not sure if it' s the right way to fix it) by specifying the old seqfile/mapfile directives, but then I'm stuck at rc_read_dictionary: invalid type on line 34 of dictionary /etc/radcli/dictionary Seems like pppd and libradcli4 have totally different ideas about radius dictionnaries. How do you guys handle it ? Finally I managed getting working this stuff, by building from sources radiusclient-ng. It's definitely something wrong with the pppd-libradcli4 stack. Eugene.
pppd incomatible with libradcli4
Hello, I'm trying to set up the VPN stack using xl2tpd/strongswan on recent Debian 9.5, and so far everything is working except radius authentication (I have a freeradius3 setup which is fully working, so I need to use it to authenticate users). Seems like pppd is totally incompatible with libradcli4: when I add plugin radius.so plugin radattr.so into the /etc/ppp/options.xl2tpd configuration file, pppd starts complaining about missing directives: first, /etc/radiusclient/radiusclient.conf cannot be read. Okay, I don't know if it's right, but since radiusclient1 seems to be vanished completely, I can link /etc/radcli as /etc/radiusclient. Then the following happens: /etc/radiusclient/radiusclient.conf: mapfile not specified /etc/radiusclient/radiusclient.conf: seqfile not specified These two can be easily (again, not sure if it' s the right way to fix it) by specifying the old seqfile/mapfile directives, but then I'm stuck at rc_read_dictionary: invalid type on line 34 of dictionary /etc/radcli/dictionary Seems like pppd and libradcli4 have totally different ideas about radius dictionnaries. How do you guys handle it ? Thanks. Eugene.
Cannot get crashdumps on iSCSI-booted system
Hello, I'm trying to get the crashdumps (to start getting them automatically later) on an iSCSI-booted buster/sid, but after issuing |"echo c > /proc/sysrq-trigger" all I'm getting is the system hangup - no dump, but the system seems to be locked - and no panic screen or whatever. Everything is frozen up. However, I'm getting crashdumps when booting from local disks. The problem is - my production hosts use iSCSI for booting, so I really need to get these crashdumps whil on iSCSI. I know that Linux isn't able to write the crashdump on "local" disk when this "local" disk is iSCSI, so I've set up the NFS crashdump resource - but to NFS activity is happening when I'm triggering the panic. | | | |Is there some trick that I'm unaware of ? | |Thanks.| |Eugene. |
some weird shape
Hi. I got a Debian 5.0.3 installation, made by some engineer before me. I got a weird problem on that host: all of the apache2 sessions are limited by 400 kBytes/sec. First I thought this is some limitation made by tc, but 'tc qdisc show' and 'tc class show' displays only defaults. Second thought - there's some apache mod, like mod_throttle or something like that. But further investigations show that there's no such thing. I didn't find any known bandwidth limiting module. This server is installed in the ISP datacenter, but this definitely cannot be made by an ISP, because localhost sessions are shaped too. So I'm writing this hoping that may be someone would have an idea about what is this, or may be someone will point me at something I forgot. Thanks. Eugene. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9dcb7f.5090...@zhegan.in
