Problems with debian packages.

[linsomniac]

Thank you very much for the debian packages. However, there are a few things I think need to be changed:

The package installs things into opt sub-directories of other directories: /etc/opt/influxdb, it uses /var/opt/influxdb... These are just the wrong places for them. Really the config file should go into /etc/influxdb.conf, or possibly /etc/influxdb/influxdb.conf (though since there is only one file, it doesn't make sense to make a directory. The database files should go into /var/influxdb.

The logrotate file is written in /etc/logrotate.d/influxd, this probably should be influxdb.

The logrotate.d file has permissions 664, they need to be 644 or logrotate ignores it.

The command-line client is installed in /opt/influxdb/versions/0.9.4/influx, which means the file name changes with every version roll and is not in the path. This should probably be installed into /usr/bin or /bin, or at the very least should have a symlink to the opt version.

Typically, packages don't put things into /opt, the packages manage the installed files so you would just put the daemon into /usr/sbin, the CLI into /bin, the init scripts either directly into /etc/init or /etc/init.d, or into /usr/share and copy/link them into /etc/init in the post install.

The package also lists a file "/.". That probably doesn't hurt anything but also could be cleaned up.

[otoolep]

Thanks for the feedback.

We are reworking the paths for the packages, so you can expect some changes
in the near future. We agree the paths need to be closer the those you
suggest, since the conventions are strong in that regard.

However the paths are not wrong if you study the Filesystem Hierarchy
Standard. It is that standard we followed.

https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

The logrotate file is named after the daemon not the product name. I'll
look into the permissions issue though - thanks for the head ups.

On Wednesday, October 14, 2015, Sean Reifschneider <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Thank you very much for the debian packages. However, there are a few
things I think need to be changed:

The package installs things into opt sub-directories of other directories:
/etc/opt/influxdb, it uses /var/opt/influxdb... These are just the wrong
places for them. Really the config file should go into /etc/influxdb.conf,
or possibly /etc/influxdb/influxdb.conf (though since there is only one
file, it doesn't make sense to make a directory. The database files should
go into /var/influxdb.

The logrotate file is written in /etc/logrotate.d/influxd, this probably
should be influxdb.

The logrotate.d file has permissions 664, they need to be 644 or logrotate
ignores it.

The command-line client is installed in
/opt/influxdb/versions/0.9.4/influx, which means the file name changes with
every version roll and is not in the path. This should probably be
installed into /usr/bin or /bin, or at the very least should have a symlink
to the opt version.

Typically, packages don't put things into /opt, the packages manage the
installed files so you would just put the daemon into /usr/sbin, the CLI
into /bin, the init scripts either directly into /etc/init or /etc/init.d,
or into /usr/share and copy/link them into /etc/init in the post install.

The package also lists a file "/.". That probably doesn't hurt anything
but also could be cleaned up.

—
Reply to this email directly or view it on GitHub
#4446.

[linsomniac]

I will say that my /etc/opt directory has exactly two entries in it: influxdb and telegraf. I sure would like if my Ansible task didn't have to do a "/opt/influxdb/versions/*/influx" to run the CLI to create my initial databases.

[otoolep]

Agreed, it is not a standard that is followed that much, so we'll be moving the binaries out of /opt for the 0.9.5 release.

[otoolep]

cc @rossmcdonald

[otoolep]

The logrotate.d file has permissions 664, they need to be 644 or logrotate ignores it.

@linsomniac -- do you have a reference for this? I don't see anything in the logrotate man pages about permissions, but I do general references on the web for this. Sounds like this was a problem, thanks.

[linsomniac]

@otoolep My reference for it is that on theUbuntu 14.04 systems I have installed it on, the logrotate script isn't running, and when I run "logrotate --debug" it says that it is skipping the file because of permissions, and everything else in the logrotate.d directory is 644.

[otoolep]

Funny, I do not see that on my 14.04 system.

On Thursday, October 15, 2015, Sean Reifschneider notifications@github.com
wrote:

@otoolep https://github.com/otoolep My reference for it is that on
theUbuntu 14.04 systems I have installed it on, the logrotate script isn't
running, and when I run "logrotate --debug" it says that it is skipping the
file because of permissions, and everything else in the logrotate.d
directory is 644.

—
Reply to this email directly or view it on GitHub
#4446 (comment).

[linsomniac]

Well, I'm running 14.04.3, 64-bit, with logrotate 3.8.7-1ubuntu. Perhaps you need to specify "logrotate --debug -f" to get it to decide to do the rotation rather than waiting until the next day? I have 3 machines running 14.04.3 machines that all have this problem. I've fixed it via Ansible changing the permissions, but the 2 new machines I spun up yesterday definitely didn't run the logrotate last night either. The one that I fixed the permissions on yesterday did run it last night.

The code in question seems to be line 787 in logrotate's config.c, as seen here:

https://github.com/logrotate/logrotate/blob/master/config.c

The code:

if (getuid() == ROOT_UID) {
    if ((sb.st_mode & 07533) != 0400) {
        message(MESS_ERROR,
            "Ignoring %s because of bad file mode - must be 0644 or 0444.\n",
            configFile);
        close(fd);
        return 0;
    }

[otoolep]

Yes, I was testing with -f.

[linsomniac]

Not sure, but it is clearly in the Ubuntu source code and the up-stream code as well.

[rossmcdonald]

Closing in favor of #4479. Any further comments should be made on the PR.