0

Ubuntu 14.04.1 LTS

apt-get update /upgrade was run last night at around 10pm. This morning people are saying that they can't get into ftp and wifi because these services are auth'd by freeradius.

Apt-get log: Start-Date: 2015-02-17 22:11:42 Commandline: apt-get upgrade Upgrade: python3-problem-report:amd64 (2.14.1-0ubuntu3.6, 2.14.1-0ubuntu3.7), php5-xmlrpc:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), php5-sqlite:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), libsystemd-login0:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), postfix:amd64 (2.11.0-1, 2.11.0-1ubuntu1), systemd-services:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), procps:amd64 (3.3.9-1ubuntu2, 3.3.9-1ubuntu2.2), php5-fpm:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), python-urllib3:amd64 (1.7.1-1build1, 1.7.1-1ubuntu0.1), php5-ldap:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), php5-common:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), python3-software-properties:amd64 (0.92.37.2, 0.92.37.3), libfreetype6:amd64 (2.5.2-1ubuntu2.2, 2.5.2-1ubuntu2.3), libsystemd-daemon0:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), libpam-systemd:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), php5-readline:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), libprocps3:amd64 (3.3.9-1ubuntu2, 3.3.9-1ubuntu2.2), udev:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), libudev1:amd64 (204-5ubuntu20.9, 204-5ubuntu20.10), php5-cli:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), unzip:amd64 (6.0-9ubuntu1.2, 6.0-9ubuntu1.3), php5-mysqlnd:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), python3-distupgrade:amd64 (0.220.6, 0.220.7), apport:amd64 (2.14.1-0ubuntu3.6, 2.14.1-0ubuntu3.7), python3-apport:amd64 (2.14.1-0ubuntu3.6, 2.14.1-0ubuntu3.7), software-properties-common:amd64 (0.92.37.2, 0.92.37.3), ubuntu-release-upgrader-core:amd64 (0.220.6, 0.220.7), linux-libc-dev:amd64 (3.13.0-44.73, 3.13.0-45.74), php5-gd:amd64 (5.5.9+dfsg-1ubuntu4.5, 5.5.9+dfsg-1ubuntu4.6), rsyslog:amd64 (7.4.4-1ubuntu2.3, 7.4.4-1ubuntu2.5) End-Date: 2015-02-17 22:12:20 /var/log/apt/history.log (END)

/var/log/freeradius Wed Feb 18 10:18:12 2015 : Info: Loaded virtual server Wed Feb 18 10:18:12 2015 : Info: Ready to process requests. Wed Feb 18 10:18:16 2015 : Error: rlm_perl: perl_embed:: module = /var/vhosts/it/radius_auth/radius_wifi_login.pl , func = authorize exit status= Can't call method "bind" on an undefined value at /var/vhosts/it/radius_auth/radius_wifi_login.pl line 212, line 751. Wed Feb 18 10:18:16 2015 : Auth: Invalid user: [meypau10] (from client uni-ventura port 0 cli EC3586AC80F6) Wed Feb 18 10:18:18 2015 : Error: rlm_perl: perl_embed:: module = /var/vhosts/it/radius_auth/radius_wifi_login.pl , func = authorize exit status= Can't call method "bind" on an undefined value at /var/vhosts/it/radius_auth/radius_wifi_login.pl line 212, line 751. Wed Feb 18 10:18:18 2015 : Auth: Invalid user: [meypau10] (from client uni-ventura port 0 cli EC3586AC80F6)

Line 212 from /var/vhosts/it/radius_auth/radius_wifi_login.pl:

my $o_ldap = Net::LDAP->new($config{'database'}{'connection'}{'ldap'}{'dsn'});
$o_ldap->bind($config{'database'}{'connection'}{'ldap'}{'bind_dn'},
              'password' => $config{'database'}{'connection'}{'ldap'}{'password'});
if (!defined($o_ldap)) {
    # the user is allowed if we failed
    logToRadius('error', '[ldap] Could not bind to server.');
    return;
}

Is it possible that some of the php5 upgrades that took place last night caused freeradius or ldap to break? How could I troubleshoot this incident and resolve? I don't have a snapshot of the server, and rolling back would be impossible because the server is in use constantly. Would it be possible to roll-back these updates only? I've made backups of /etc/freeradius/* and /var/vhosts/it/radius_auth/

  • I think it's because the server cannot resolve to our domain controller. when I try to ping our domain controller by name, it doesn't resolve. – JasonC Feb 18 '15 at 18:59
  • Ok so we resolved this due to temp nameserver entries were not saved after a restart. In /etc/resolvconf/resolv.conf.d/base I added: nameserver 10.x.x.x nameserver 10.x.x.x then ran resolvconf -u to have it update Restarted services, and the name resolved and the services started successfully. – JasonC Feb 18 '15 at 19:15
0

Ok so we resolved this due to temp nameserver entries were not saved after a restart. In /etc/resolvconf/resolv.conf.d/base I added: nameserver 10.x.x.x nameserver 10.x.x.x then ran resolvconf -u to have it update Restarted services, and the name resolved and the services started successfully.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.