Home / user-228027

user2743554's questions

Martin Hope
user2743554
Asked: 2017-12-19 07:49:28 +0800 CST
  • 1

By default, Unbound DNS server works by "classic" scheme: queries root servers for zone NS records, then queries NS'es for A/AAAA/...

Sometime (rarely) connectivity between my DNS and target NS'es is failed, but target NS'es are still available from various LookingGlasses and from Google/Level3 DNS, so "nslookup www.target.com 8.8.8.8" and "nslookup www.target.com 4.2.2.2" returns the correct answer.

How to setup Unbound to use public forwarders when (and only after) direct query to the target NS'es is failed? The following config works fine, but routes all queries immediately to forwarders, ignoring target NS'es at all:

forward-zone:
    name: "."
    forward-first: no
    forward-addr: 8.8.8.8
    forward-addr: 4.2.2.2
domain-name-system
Martin Hope
user2743554
Asked: 2017-12-13 10:08:49 +0800 CST
  • 0

There are many HTTPS-servers (Nginx or Haproxy or something else?):

  • single balancer,
  • and multiple workers.

Is it possible to migrate an established HTTPS session (with HTTP request headers already received) from balancer to worker?

  • Balancer should completely forget about this session.
  • Worker should receive the rest of HTTP request body and send HTTP response directly to client over SSL (omitting balancer).

This seems relatively trivial for plain HTTP because it's unencrypted, but seems a bit difficult for HTTPS because session-specific SSL handshake params should be (transparently for client):

  1. Serialized by balancer,
  2. Transferred to worker,
  3. Deserialized by worker,
  4. Applied by worker.

The nearest feature I've found is named "SSL connection mirroring" and is the part of F5 BIG-IP platform. It demonstrates that described problem is practically solvable. But it's (a) proprietary, (b) extremely high-priced and (c) failover-only solution, i.e. HA without LB.

nginx
Martin Hope
user2743554
Asked: 2017-07-07 07:28:25 +0800 CST
  • 1

There is a daemon that can be started from command line and from systemctl.

/etc/systemd/system/mydaemon.service contains ExecStart= and PIDFile= so Systemd can surely detect that service is running or not:

[Unit]
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mydaemon --no-fork
PIDFile=/var/run/mydaemon-%i.pid

[Install]
WantedBy=multi-user.target

Why "systemctl status mydaemon" says that daemon is stopped even if it's running?

How to teach systemd that daemon can be running not only via "systemctl start" but also directly?

systemd
Martin Hope
user2743554
Asked: 2017-03-25 07:30:58 +0800 CST
  • 0

There is a Linux server with several Intel 82599ES cards:

# lspci | grep -i eth
01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

# ethtool -i enp1s0f0 | grep firmware-version
firmware-version: 0x18b30001

# ethtool -i enp2s0f0 | grep firmware-version
firmware-version: 0x800004d0

How to flash the newest firmware to these cards? Is it possible without rebooting?

nic
Martin Hope
user2743554
Asked: 2016-02-05 11:01:50 +0800 CST
  • 4

The same effect on many servers with various kernel versions.

There are multiple Iptables DNAT rules:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 12345 -j DNAT --to-destination 10.20.30.40:5678
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 23456 -j DNAT --to-destination 10.11.12.13:5789
....
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 34567 -j LOG --log-prefix 'natudp: '
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 34567 -j DNAT --to-destination 10.55.66.77:34567

Problem: UDP rules are not working for incoming requests from eth0.
Packet and bytes counters for them have zero values.
Simplification (removing dport) has no effect.
As result, requests are passed to filter/INPUT chain instead of FORWARD.

No such problem for packets from virtual interfaces (tap, veth) - they are trapped by prerouting rules.
No such problem for TCP.
No such problem for UDP answers.
But incoming UDP requests from eth0 are ignored by prerouting rules at all:

# iptables -t nat -nvL PREROUTING
Chain PREROUTING (policy ACCEPT 3 packets, 174 bytes)
 pkts bytes target   prot opt in     out   source        destination         

(testing rules)
    2   126 LOG      udp  --  *      *     0.0.0.0/0     0.0.0.0/0      LOG flags 0 level 4 prefix "prerouting-udp: "
    0     0          udp  --  *      *     1.2.3.4       0.0.0.0/0               
    0     0          udp  --  *      *     1.2.3.4       0.0.0.0/0      udp dpt:25826
    0     0          udp  --  eth0   *     0.0.0.0/0     0.0.0.0/0      udp dpt:25826
    0     0          udp  --  eth0   *     1.2.3.4       0.0.0.0/0           
    0     0          udp  --  eth0   *     1.2.3.4       0.0.0.0/0      udp dpt:25826

(production rules)
    7   412 DNAT     tcp  --  eth0   *     0.0.0.0/0     0.0.0.0/0      tcp dpt:12345 to:10.20.30.40:8080
   63  3804 DNAT     tcp  --  eth0   *     0.0.0.0/0     0.0.0.0/0      tcp dpt:56789 to:10.30.40.50:8000
    0     0 DNAT     udp  --  eth0   *     1.2.3.4       0.0.0.0/0      udp dpt:25826 to:10.40.50.60:25826

Any ideas?

iptables