Hi,
I am a (delighted!) relatively new BF user and run two dozen websites under Centos and Virtualmin, with no email as I keep email off my webserver.
I am fed up with Cpanel in multiple ways and want to drop the server where I currently have all my email and mail forwarders.
Is another VPS on Centos with Virtualmin a good route to manage my and my clients’ email?
Or is there a better solution for a mail server?
Cheers
Hugh
Hi Everyone,
I'm stuck in a never-ending conference call at work because of
significant enterprise-wide outages. These outages have been caused by
apparently valid certificates failing to verify.
Our investigation has revealed that the AddTrust Root CA certificate
expired today but our certificate issuer sold us 2 year certs without
checking every cert in the chain of trust was valid until the expiry
date of the certs we bought (There was only 1 year remaining on the Root
CA cert on the day they sold us a 2 year cert signed with it.)
You may wish to check the chains of trust on your certificates...
All the best,
Paul.
Bitfolk's monitoring service is great:
https://tools.bitfolk.com/wiki/Monitoring
but it just occurred to me that (IIUC) it only monitors for *reachable*
services, not for unreachable ones - i.e. whether the firewall is
correctly shielding a particular port or protocol.
Now, I know that best practice is to ensure that all running services are
correctly configured to only listen to traffic from the networks from which
they can safely receive it, and that a good sysadmin should be able to
sleep comfortably at night even when his firewall is off (wide open).
However, that does not invalidate defence in depth; I don't think anyone
who advocates the above best practice would seriously recommend ditching
firewall rules. Therefore it makes sense (to me, at least) to try to
implement at least some basic tests to monitor the correct behaviour of the
firewall.
The kind of test I imagine is an attempted connection to a TCP or UDP port
which passes when the response is ICMP port unreachable (in the case of a
REJECT rule), or when a timeout expires without any response (in the case
of a DROP rule). The test could fail if a RST was received in the TCP
case, or in any case if any other response was received.
Of course there are way too many ports for such a monitor to check them
all, but even checking a single port for which no services are expected to
be running would be a lot better than nothing, since this could catch a
large number of cases where basic firewall configuration errors have been
made, or where the firewall was accidentally turned off or simply failed to
start.
Does this make sense or has the sun gone to my head?
Cheers,
Adam
Hi,
Ubuntu 20.04 is scheduled to be released at some point today. As
things stand its kernel won't boot at BitFolk.
I think it's due to some bugs in Xen's LZ4 decompression. These
problems have since been fixed but it would mean a forced reboot to
deploy them and I'm not going to do that, for this.
I will let you know when there is a host available that will boot
these LZ4-compressed kernels, so if you are desperate to upgrade to
20.04 you can be moved there.
If you already did try to upgrade to 20.04 and now it doesn't boot,
your previous (18.04) kernel will boot, which clearly isn't ideal
but does at least regain access.
Possibly you could build a custom kernel that doesn't use LZ4 or
find a way to unpack (and optionally repack) the existing vmlinuz.
I'll follow up with more info as I experiment with that.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Afternoon
I'm hoping someone can point me in the direction of a fix for my current
nftables config.
From the command line I can run the following:
sudo nft add table nat
sudo nft add chain nat post { type nat hook postrouting priority 0 \; \}
sudo nft add chain nat pre { type nat hook prerouting priority 0 \; \}
sudo nft add rule nat post ip saddr 10.10.10.0/24 oifname "eth0" masquerade
Listing my running nft rules shows this appended to the end:
table ip nat {
chain post {
type nat hook postrouting priority 0; policy accept;
ip saddr 10.10.10.0/24 oifname "eth0" masquerade
}
chain pre {
type nat hook prerouting priority 0; policy accept;
}
I then try to transfer that config to my nftables.conf but on reading in
the .conf file I get the errors:
sudo nft -f /etc/nftables.conf
/etc/nftables.conf:67:1-5: Error: syntax error, unexpected table
table ip nat {
^^^^^
/etc/nftables.conf:70:55-64: Error: NAT is only supported for IPv4/IPv6
ip saddr 10.10.10.0/24 oifname "eth0" masquerade
I'm obviously missing some piece of information here that will allow me
to fix it.
If you'd like to help me add the masquerade for IPv6 as well that would
be brilliant.
Hopefully someone has the answer as I currently stumped
Cheers
Steve
