• 1 Post
  • 128 Comments
Joined 1 year ago
cake
Cake day: January 17th, 2024

help-circle
  • Half off-topic, sorry: if you have some spare time on the weekend, you might want to take a look at nftables. AFAIK iptables is also just using nftables under the hood, so you are basically using a deprecated technology.

    nftables is so much nicer to work with. In the end I have my custom rules (which are much saner to define than in iptables) in /etc/nftables.conf, then I have a very simple systemd unit:

    [Unit]
    Description=Restore nftables firewall rules
    Before=network-pre.target
    
    [Service]
    Type=oneshot
    ExecStart=/usr/sbin/nft -f /etc/nftables.conf
    ExecStop=/usr/sbin/nft flush table inet filter
    RemainAfterExit=yes
    
    [Install]
    WantedBy=multi-user.target
    

    and finally if I push updates via ansible I simply replace the file and run nft -f /etc/nftables.conf (via ansible; on-change event).

    Edit: oh and as an example how the actual rules file looks like:

    #!/usr/bin/nft -f
    
    add table inet filter
    flush table inet filter
    
    table inet filter {
      chain input {
        type filter hook input priority 0;
    
        # allow established/related connections
        ct state {established, related} accept
    
        # early drop of invalid connections
        ct state invalid drop
    
        # allow from loopback
        iifname lo accept
    
        # allow icmp
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept
    
        # core services
        tcp dport {80, 443} accept comment "allow http(s)"
        udp dport 443 accept comment "allow http3"
    
        # everything else
        reject with icmpx type port-unreachable
      }
    
    }
    

    and with that I have my ipv4+6 firewall that allows pings and http







  • I can understand Hellwig’s fear, though.

    From what I gather as a bystander, it’s apparently common that a refactoring in your module that breaks its API will involve fixing all the call-sites to keep the effort on the person responsible for the change. Now the Rust maintainers say “it’s fine; if it breaks, we’ll deal with it” which is theoretically takes away the cross-language issue for the C-maintainer. Practically I can very well see, that this will still cause friction in the future.

    Let’s say such a change happens and at that time there’s a bit of time pressure and the capacity on the rust maintainers is thing for whatever reasons. Will they still happily swallow that change or will they start to discuss if it’s really necessary to do that change? And suddenly, the C-maintainer has a political discussion on top of the technical issue they wanted to solve.

    As someone who just wants to get shit done, I would definitely have that fear.

    (That doesn’t mean it’s still a bullet not worth swallowing. The change overall can still be worth the friction. I am just saying that I think it’s not totally unwarranted that a maintainer feels affected by this even though current pledges from the other parties promise otherwise; this stance can change or at least be challenged over and over.)


  • It was an example. I don’t have a fucking clue how all the maintainers are named.

    The main question was: why can a maintainer NACK something not in their responsibility? Isn’t it simply necessary to find one maintainer who is fine with it and pulls it in?

    Or even asked differently: shouldn’t you need to find someone who ACKs it rather than caring about who NACKs it?













  • glibc’s malloc increases the stacksize of threads depending on the number of cpu cores you have. The JVM might spawn a shitload of threads. That can increase the memory usage outside of the JVMs heap considerably. You could try to run the jvm with tcmalloc (which will replace malloc calls for the spawned process). Also different JVMs bundle different memory allocators. I think Zulu could also improve the situation out of the box. tcmalloc might still help additionally.