[gentoo-user] Re: OT:: free pop3 mail box?
If you have or can get a fixed IP address and own domain name, check out ispconfig.org (mail, web, dns, ftp) and iredmail.org (mail). You can run either in VirtualBox with 500K ram or on a old laptop. Both run on top of Debian, Ubunto, OpenSuse. I was some years ago annoyed with my mail provider and decided to run IRedMail in VirtualBox. Now it's ISPconfig on an old laptop in VirtualBox to server as Mail, Web and local DNS server. Hans On 08/10/15 02:07, James wrote: Folks, I do not want gmail or any other big (brother) organization email. I just need a simple pop3 (small) email box, in case my (underconstruction) email server is not happy. Low traffic. Temporary is fine too. Suggestions most welcome. Tia, James
Re: [gentoo-user] persistent /run/* ownership/permissions
>> I have to chown munin:nginx and chmod g+x on directory /run/munin/ >> after every reboot. The munin list suggests altering the initscript >> but is there a better way? > > > There are ways, but I wouldn't call them better. > > /run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot > anyway. The initscript is the perfect place to do it. There's lots of > examples in most /etc/init.d, so I suggest submit a working patch to b.g.o. OK will do, thank you. - Grant
Re: [gentoo-user] strange TCP timeout errors
> It's as I thought - your data is accurate but rrd has been given a > completely wrong method to derive the graphs. > > Munin graphs for section "Network" do not have to be in a file called > "network" - it's just a category and the plugin defines what web-page > section it must be in. In your case, the relevant plugin is > netstat_multi which doesn't often get installed. It's data source is > "netstat -s" so grep that output for "timeout" to see it. > > Timeouts are cumulative counters, they do not get less till they wrap > around. So to scale them, the plugin gets the rrd file to subtract > previous reading from current reading and divide by the time interval to > get the timeouts/sec. This is all done inside rrd when the data files > are updated (it's quite a lot of magic) > > That plugin sets the graph type to DERIVE > (/etc/munin/plugins/netstat_multi around line 190. I feel it should be > GAUGE or COUNTER. > > The proper reference on rrd is > http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html > and the munin docs are > https://munin.readthedocs.org/en/latest/index.html > > You must edit the plugin file and IIRC recreate the rrd, you will lose > all past info (can't be helped). > > > [snip ls output] > > >> P.S. Any other good plugins you'd recommend? > > http://gallery.munin-monitoring.org/ > > Monitoring is highly site-specific so recommendations aren't usually > worth much, but that gallery has LOTS of contributed plugins Many thanks Alan! - Grant
[gentoo-user] Re: persistent /run/* ownership/permissions
Alan McKinnonwrote: > On 07/10/2015 18:27, Grant wrote: >> I have to chown munin:nginx and chmod g+x on directory /run/munin/ >> after every reboot. The munin list suggests altering the initscript >> but is there a better way? > > There are ways, but I wouldn't call them better. The way to do it nowadays would be by placing a file with the content d /run/munin 0775 munin nginx into /usr/lib/tmpfiles.d (if done by the distribution) or into /etc/tmpfiles.d (if this is only needed for your special setup). > /run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot > anyway. The initscript is the perfect place to do it. No, it is not the perfect place, because such a thing would be strange to do if e.g. the initscript is restarted or started only very late for some reasons (possibly hours after the system start, if munin is not needed immediately.) (OK, in /run it is not a security risk, but in world-writable directories there exist symlink attacks or other bad things if you create dirs/files too late and with a predictable name. For dirs, it might be possible if you are *very* careful, but the obvious "mkdir ...; chown ...; chmod ..." would be a horrible security failure.) Moreover, it is an init-system specific solution while you can have a general solution. Meanwhile, at least openrc and systemd both support the tmpfiles.d subdirectories; I do not know the state of other init-systems, but it is not hard to extend any init-system of your choice to support these directories. In any case, they are more compatible than a solution which works with only *one* init-system.