Rovanion's questions

I've set up Prometheus' Alertmanager to, well, manage alerts from Prometheus. I've got the alerts coming in from Prometheus to Alertmanager, but there the story ends. The alerts never get sent on by Alertmanager to my email endpoint.

In order to figure out where exactly inside Alertmanager that the alerts end their journey I want to turn the log level from info to debug, but have been unable to figure out how. Even finding the log seems like a tough ask right now, its not in /var/log and journalctl -u alertmanager contains so little that it may be that there is another log somewhere.

The manual page for configuring Alertmanager does not mention debug level. I've looked through the source code for mentions of log and found that the setting should be named log.level. Adding the following snippet to the configuration YAML didn't help either:

log:
  level: debug

as Alertmanager failed to start with a failure to parse its config file.

Introduction

A common scenario for a web application that it has two general folders. One filled with code which is executed by the application server, for example uwsgi, and one with static content directly delivered by the web server, for example nginx.

On a Debian server the user account for the web server is www-data while the application server normally is unique per application. This means that in the code file can have the following acl:

# file: code/main.py
# owner: user
# group: user
user::rwx
group::rwx
group:app-server:rwx
other::---

While a static file can have the following ACL:

# file: static/bootstrap.css
# owner: user
# group: user
user::rwx
group::rwx
group:app-server:rwx
group:www-data:r--
other::---

The actual question

How is it possible that a file with these permissions:

$ sudo getfacl /srv/domain/django/static_files/bootstrap/css/bootstrap.css
getfacl: Removing leading '/' from absolute path names
# file: srv/domain/django/static_files/bootstrap/css/bootstrap.css
# owner: user
# group: user
user::rwx
group::rwx
group:www-data:r--
group:app-server:rwx
group:user-organization:rwx
mask::rwx
other::---

Is not readable by www-data:

$ sudo -u www-data cat /srv/domain/django/static_files/bootstrap/css/bootstrap.css
cat: /srv/domain/django/static_files/bootstrap/css/bootstrap.css: Permission denied

When the user www-data clearly is a member of the group with the same name:

$ id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

In fact relinquishing all control and allowing anyone to read does nothing to help the situation:

$ sudo chmod 774 /srv/domain/django/static_files/bootstrap/css/bootstrap.css
$ sudo getfacl /srv/domain/django/static_files/bootstrap/css/bootstrap.css
getfacl: Removing leading '/' from absolute path names
# file: srv/domain/django/static_files/bootstrap/css/bootstrap.css
# owner: user
# group: user
user::rwx
group::rwx
group:www-data:r--
group:app-server:rwx
group:user-organization:rwx
mask::rwx
other::r--
$ cat /srv/domain/django/static_files/bootstrap/css/bootstrap.css
cat: /srv/domain/django/static_files/bootstrap/css/bootstrap.css: Permission denied

Changing the ownership and group of the file over to www-data with chown and chgrp doesn't change the outcome. I find nothing of interest in dmesg, messages or auth.log.

So something is going on, but I'm all out of ideas.

I've got two identical users, one can access the share while the others not able to. The share's name is storage_photos, it's located in the folder /storage/photos/.

$ getfacl /storage/photos
getfacl: Removing leading '/' from absolute path names
# file: storage/photos
# owner: root
# group: photos
user::rwx
group::rwx
group:photos:rwx
mask::rwx
other::r--
default:user::rwx
default:group::rwx
default:group:photos:rwx
default:mask::rwx
default:other::r--

The two users in question are both members of the photos group:

$ groups john
john : john sambashare photos

$ groups lisa
lisa : lisa sambashare photos

And as of their membership in the sambashare folder they're able to list /var/lib/samba/usershares/:

sudo -u lisa ls -ltha /var/lib/samba/usershares/
total 24K
drwxrwx--T 2 root sambashare 4.0K Oct 25 17:06 .
-rw-r--r-- 1 root root        125 Oct 25 17:06 storage_photos

With this in mind it's strange to find that one user fails to access the share while the other succeeds:

smbclient //Server/storage_photos -U lisa%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED

smbclient //Server/storage_photos -U john%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
smb: \>

On the server side the failure, with logging level 2, looks like:

[2015/10/25 23:12:20.646681,  0] ../source3/param/loadparm.c:4365(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied
[2015/10/25 23:12:20.649381,  2] ../source3/smbd/service.c:407(create_connection_session_info)
  guest user (from session setup) not permitted to access this share (storage_photos)
[2015/10/25 23:12:20.649437,  1] ../source3/smbd/service.c:550(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

Meanwhile the success is a boring:

[2015/10/25 23:14:30.321507,  2] ../source3/smbd/service.c:856(make_connection_snum)
  device (ipv4:192.168.1.5:46134) connect to service storage_photos initially as user john (uid=1000, gid=1000) (pid 5297)
[2015/10/25 23:16:10.409218,  1] ../source3/smbd/service.c:1130(close_cnum)
  device (ipv4:192.168.1.5:46134) closed connection to service storage_photos

Now the interesting part from the failure is the following: process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied. Why would the access fail even though the user can stat the file:

sudo -u lisa stat /var/lib/samba/usershares/storage_photos
  File: ‘/var/lib/samba/usershares/storage_photos’
  Size: 125             Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 137795      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-10-25 17:06:46.704318935 +0100
Modify: 2015-10-25 17:06:46.700318935 +0100
Change: 2015-10-25 17:06:46.700318935 +0100
 Birth: -

From this one would draw the conclusion that for some reason samba isn't using the correct unix user to stat the file when lisa tries to log in but is when john does.

Both john and lisa can ssh to the machine. The machine does have libpam-smbpass installed as prescribed in this stack overflow question. But having restarted the server the issue persists.

All of this is using the following, very default, Ubuntu 14.04 smb.conf. The shares are defined by ZFS filesystems having the sharesmb parameter on.

[global]  
        workgroup = ONE  
        server string = %h server (Samba, Ubuntu)  
        server role = standalone server  
        map to guest = Bad User  
        obey pam restrictions = Yes  
        pam password change = Yes  
        passwd program = /usr/bin/passwd %u  
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .  
        unix password sync = Yes  
        syslog = 0  
        log file = /var/log/samba/log.%m  
        max log size = 1000  
        dns proxy = No  
        usershare allow guests = Yes  
        panic action = /usr/share/samba/panic-action %d  
        idmap config * : backend = tdb

In the organization wide Active Directory we have user groups that all begin with a prefix blaha-, how do I list all groups with that prefix on a Linux machine?

getent group only seems to list local groups even though the machine's pam is connected to AD. Doing getent group blha-group correctly lists the users in the AD group, but the group doesn't appear in the list produced by getent group.

So basically I'd like a command along the lines of getent group blaha-* where * is expanded to any number of characters.

In the init script of nginx in Debian 7 (Wheezy) I read the following exerpt:

status)
            status_of_proc -p /var/run/$NAME.pid "$DAEMON" nginx && exit 0 || exit $?
            ;;

This code runs just fine and sudo service nginx status outputs [ ok ] nginx is running. Yet status_of_proc is not defined in bash, neither in dash:

$ type status_of_proc
status_of_proc: not found

Though if I inserted the same check into the nginx-script I got the following result:

status_of_proc is a shell function

And running bash on the init file itself provided further explanation:

status_of_proc is a function
status_of_proc () 
{ 
    local pidfile daemon name status OPTIND;
    pidfile=;
    OPTIND=1;
    while getopts p: opt; do
        case "$opt" in 
            p)
                pidfile="$OPTARG"
            ;;
        esac;
    done;
    shift $(($OPTIND - 1));
    if [ -n "$pidfile" ]; then
        pidfile="-p $pidfile";
    fi;
    daemon="$1";
    name="$2";
    status="0";
    pidofproc $pidfile $daemon > /dev/null || status="$?";
    if [ "$status" = 0 ]; then
        log_success_msg "$name is running";
        return 0;
    else
        if [ "$status" = 4 ]; then
            log_failure_msg "could not access PID file for $name";
            return $status;
        else
            log_failure_msg "$name is not running";
            return $status;
        fi;
    fi
}

Yet inserting the same function call into an init script made by myself returned that the function was undefined. So it has nothing to with init scripts being special. Neither is it declared previously in the init script. Around the net I read that it is part of the LSB, but I can't figure out how call it. Will someone please help me figure out how to use this wonderful function?