Re: [pmacct-discussion] pmacct.net

2022-05-08 Thread Paolo Lucente



A quick note to thank you Karl for your always good inputs; let me read 
through and see what actions i can take.


Paolo


On 4/5/22 13:32, Karl O. Pinc wrote:

Hi Paolo,

On Wed, 4 May 2022 01:25:23 -0300
Paolo Lucente  wrote:


Somehow i can't reproduce the problem, both pmacct.net and
www.pmacct.net do actually work for me no problem (http of course,
ie. not https, well no https is advertised out nor does it work).

Can you please qualify the issue better (here or by unicast email).


I'm using Mozilla Firefox 91.8.0esr on Debian bullseye (v11.3).

Some browsers of late (I think firefox, at least
in private windows, and maybe other browsers) use
https by default.   So, it's a https problem.  Just typing
"pmacct.net" resulted in a "can't connect" type of message.

https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/

According to the above, this should not be a problem.
But my ISP sucks; dns resolution is slow.  So there's
probably a race condition.  One that does not affect
very many people.



Should you decide to use HTTPS, here's my certbot command
(for the debian certbot package which uses the free letsencrypt.org
service):

certbot certonly --webroot \
  --webroot-path /var/www/webserver \
  --domains foo.example.com,bar.example.com,... \
  --renew-with-new-domains

I prefer not to let certbot frob the webserver configs.  So you'll
then need to add the cert files found in
/etc/letsencrypt/live// to the TLS configs for your
webserver.  (See /etc/letsencrypt/live/README.)

The debian certbot package comes with a systemd timer to renew
the certs.  (And a systemd service.)  They probably come
enabled out of the box but check with "systemctl status ...".

As an FYI, the way certbot issuance/renewal works is that first a cookie
is obtained and dropped into the http document root.  When the
letsencrypt server verifies the cookie using http, it knows that you
run the website and then issues you a cert.

See also:

https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html

FWIW, using HTTPS is supposed to get you a better google ranking.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
  -- Robert A. Heinlein

P.S.  If you want to use the certbot web cert to secure your
SMTP traffic I have a hook I can send you that works with postfix.
You'll have to frob it to get the certs onto your secondary MX.


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists


Re: [pmacct-discussion] [docker-doctors] pmacctd in docker

2022-05-08 Thread Paolo Lucente


Hi Thomas,

The simplest thing i may recommend is to check it all working outside a 
container - this way you can easily isolate whether the issue is somehow 
related to the container (config or interaction of pmacctd with the 
container) or with the pmacct config itself.


Paolo


On 6/5/22 06:05, Thomas Eckert wrote:

Hi everyone,

pmacct starter here, trying to get pmacctd working inside of a container 
to listen to the (container's) host's traffic. I suppose this is a, if 
not the, standard use case for pmacctd in a container. So I'm sure it 
works in principle but I'm doing something wrong.


Command for starting the container:
     docker run \
         --privileged --network=host \
         --name pmacctd \
         -v /tmp/pmacctd.conf:/etc/pmacct/pmacctd.conf:ro \
         -v /tmp/pcap-itf.conf:/etc/pmacct/pcap-itf.conf:ro \
         -v /tmp//captures:/var/pmacct/captures:rw pmacctd-debug \
         pmacct/pmacctd:latest

Contents of pmacctd.conf:
     daemonize: false
     snaplen: 1000
     pcap_interfaces_map: /etc/pmacct/pcap-itf.conf
     aggregate: src_host, dst_host, src_port, dst_port, proto, class
     plugins: print
     print_output: json
     print_output_file: /var/pmacct/captures/capture-%Y%m%d_%H%M.txt
     print_output_file_append: true
     print_history: 1m
     print_history_roundoff: m
     print_refresh_time: 5

pcap-itf.conf contains all interfaces of the host (as per netstat -i) in 
the form

     ifname=eno2
One line each, no other keys/values other than ifname.
Possibly important note: There's a VPN (openconnect) constantly running 
on the host. The VPN's interface is listed in netstat -i and, as such, 
included in pcap-itf.conf.


Starting the container yields this output:
     INFO ( default/core ): Promiscuous Mode Accounting Daemon, pmacctd 
1.7.7-git (20211107-0 (ef37a415))
     INFO ( default/core ):  '--enable-mysql' '--enable-pgsql' 
'--enable-sqlite3' '--enable-kafka' '--enable-geoipv2' 
'--enable-jansson' '--enable-rabbitmq' '--enable-nflog' '--enable-ndpi' 
'--enable-zmq' '--enable-avro' '--enable-serdes' '--enable-redis' 
'--enable-gnutls' 'AVRO_CFLAGS=-I/usr/local/avro/include' 
'AVRO_LIBS=-L/usr/local/avro/lib -lavro' '--enable-l2' 
'--enable-traffic-bins' '--enable-bgp-bins' '--enable-bmp-bins' 
'--enable-st-bins'
     INFO ( default/core ): Reading configuration file 
'/etc/pmacct/pmacctd.conf'.

     INFO ( default/core ): [/etc/pmacct/pcap-itf.conf] (re)loading map.
     INFO ( default/core ): [/etc/pmacct/pcap-itf.conf] map successfully 
(re)loaded.
     INFO ( default_print/print ): cache entries=16411 base cache 
memory=67875896 bytes

     INFO ( default_print/print ): JSON: setting object handlers.
     INFO ( default_print/print ): *** Purging cache - START (PID: 7) ***
     INFO ( default_print/print ): *** Purging cache - END (PID: 7, QN: 
0/0, ET: X) ***


Now, the problem is there are no files showing up in the 'captures' 
directory at all.


I tried these things  (as well as combinations thereof) to try to 
understand what's going on:
* change the time related settings in pmacct.conf: to dump data 
more/less often - also waited (increasingly) long, at times up to 20 minutes
* change 'snaplen' in pmacct.conf up & down - just to make sure I'm not 
running into buffering problems (just guessing, haven't read pmacct/d 
sources)
* change pcap-itf.conf to contain all interfaces or only the (host's) 
LAN + VPN interfaces (removing all others like docker's internal 'docker0')
* check permission settings of the 'captures' directory - this should be 
fine because a simple "touch /var/pmacct/captures/foobar" works and the 
file does exist as observed in the directory on the host itself
* run the container _not_ in host-sniffing mode, so just inside its own 
network-bubble, then cause traffic against it and observe it writing 
data to the 'captures' directory - works!


Because I started to doubt my own sanity I asked one of our Docker/K8S 
experts to check my docker setup and he found no problem looking over 
it, including via "docker inspect pmacct". So I'm fairly sure my mistake 
is somewhere in the configuration of pmacctd but I cannot figure out 
what is. Would someone please point it out to me ?


Regards & Thanks,
   Thomas

PS: It's been almost 10 years since I've posted to a mailing list. 
Please forgive any conventions/best-practices missteps.



___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists