I'm looking to migrate a process that generates client certificates from a custom root CA into hashicorp vault.
The root is already trusted by a lot of applications, so I'd like to import it (or an intermediate) into vault and emit the client certificates from there.
The tutorials are straightforward but always show how to generate a new root and intermediate certificate.
How can I initialize a PKI secrets engine with a pre-existing root cert via command-line (e.g. vault write pki/root/???) ?
How can I reload the running NetworkManager routing configuration from the route-XXX files in a Centos/RHEL7 server?
I have a few servers which get routes updated directly via the /etc/sysconfig/network-scripts/route-XXX files (part of a legacy deployment process), but when there are new routes, NetworkManager won't see the changes.
I've tried nmcli connection reload and nmcli connection up ens192 without success, the running routing table is not modified.
I'm aware that the proper way would be to run a few nmcli connection modify +ipv4.routes ... commands, but for this particular case the reload from file is necessary.
Is there any systemd unit that should be restarted/reloaded to achieve this?
I'm experiencing random issues on a DNS resolver running BIND 9.8.2 (RHEL6) behind a loadbalancer.
The loadbalancer is actively probing the server with a DNS query to find if it's alive, and every now and then it gets a "Connection refused" (ICMP) for port 53, which briefly makes the server unavailable for service in the loadbalancer server pool.
This happens intermittently (the LB probes every 10 seconds, and we usually see 1 or 2 failures, followed by successes) for several minutes at a time, and then stops, it happens during peak load times but it has been detected when the traffic is at the lowest.
When the issue occurs BIND is up and running, which makes the "connection refused" message confusing, I would expect that from a server with no listening service on port 53, which is not the case. Even if the DNS resolution failed for the probing record, the answer would be a NXDOMAIN or SERVFAIL, not a flat-out UDP rejection.
The query logs don't show the failing probes, which means the UDP packet is rejected before being delivered to BIND for processing.
My best guess is that this is caused by resource exhaustion of some sort, but I can't figure out what exactly. We're monitoring open file descriptors, net.netfilter.nf_conntrack_count, CPU, memory, recursive-clients, etc. and none of those indicators even approach the limits when the issue hits.
None of the log files has any relevant error messages at the times when the issue occurs.
So, my question: what networking metrics/parameters should I look into?
Configuration
/etc/sysconfig/named
OPTIONS="-4 -n10 -S 8096 "
named.conf
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
statistics-file "/var/named/named.stats";
dump-file "/var/named/named_dump.db";
zone-statistics yes;
version "Not disclosed";
listen-on-v6 { any; };
allow-query { clients; privatenets; };
recursion yes; // default
allow-recursion { clients; privatenets; };
allow-query-cache { clients; privatenets; };
recursive-clients 10000;
resolver-query-timeout 5;
dnssec-validation no;
//querylog no;
allow-transfer { xfer; };
transfer-format many-answers;
max-transfer-time-in 10;
notify yes; // default
blackhole { bogusnets; };
// avoid reserved ports
avoid-v4-udp-ports { 1935; 2605; 4321; 6514; range 8610 8614; };
avoid-v6-udp-ports { 1935; 2605; 4321; 6514; range 8610 8614; };
max-cache-ttl 10800; // 3h
response-policy {
zone "rpz";
zone "rpz2";
zone "static";
};
rate-limit {
window 2; // seconds rolling window
ipv4-prefix-length 32;
nxdomains-per-second 5;
nodata-per-second 3;
errors-per-second 3;
};
};
Edit: UDP receive errors
$ netstat -su
IcmpMsg:
InType3: 1031554
InType8: 115696
InType11: 178078
OutType0: 115696
OutType3: 502911
OutType11: 3
Udp:
27777696664 packets received
498707 packets to unknown port received.
262343581 packet receive errors
53292481120 packets sent
RcvbufErrors: 273483
SndbufErrors: 3266
UdpLite:
IpExt:
InMcastPkts: 6
InOctets: 2371795573882
OutOctets: 13360262499718
InMcastOctets: 216
Edit 2: network memory sizing
$ cat /proc/sys/net/core/rmem_max
67108864
$ cat /proc/sys/net/ipv4/udp_mem
752928 1003904 1505856
Edit 3: No issue with UdpInErrors
Had a probe failure event with no corresponding increase in UDP packet receive errors, so that seems to be ruled out as a cause.
Edit 4: there may be 2 issues at play here, some instances of failures have corresponding UdpInErrors increases, and some don't
I've found an occurrence which correlates to a problem with UDP receive errors:
I have already increased the kernel memory values to:
# cat /proc/sys/net/core/wmem_max
67108864
# cat /proc/sys/net/core/rmem_max
67108864
# cat /proc/sys/net/ipv4/udp_rmem_min
8192
# cat /proc/sys/net/ipv4/udp_wmem_min
8192
It does not seem to be load-related, similar servers with the same and even bigger workloads show no issues, while at the same time the other server behind the same loadbalancer showed the exact same behaviour during that time period.
Edit 5: found some evidence of TCP issues in BIND's statistics-channels data
Found a correlation between the high UDP packet receive errors and the TCP4ConnFail and TCP4SendErr metrics from BIND's statistics-channels data.
While the increase does not have the same scale as the UDPInErrors, it correlates strongly with it, since this effect is not present during other times.
Edit 6: the plot thickens... syslog seems to be a contributing factor
The affected DNS servers are configured to log querylogs to syslog's local0 facility, which in turn forwards them via UDP to a remote server. This has been a cause for performance issues in the past, in fact we don't have it enabled on the busiest DNS servers for that reason.
I tried disabling querylogging and it seemed to make the udpInErrors issues disappear, so I've set up an experiment. We have 2 servers behind the same loadbalancer, I've kept serverA with querylogging active as a control, and disabled querylogging (and thus syslog's forwarding) on serverB. The issue stopped occurring on both servers at the exact same time.
Then I re-enabled querylogging on serverB, and the issue reappeared, once again on both servers!
This was tried on 2 separate occasions, once under light workload and once at the busiest time, and it manifested only at the busy time, so it seems to be in part related to load.
The graphs below show the relationship between network traffic and UDP receive errors.
ServerB
ServerA
The same increase effect can also be found in the TCP indicators mentioned in edit 5.
So the root cause seems to be related to networking, which cascades and creates all the symptoms shown. The tricky part is that these servers (virtual machines, actually) run on separate infrastructure (different racks, even rooms, at times) so there should not be any effect propagation between them.
It doesn't seem to be related to querylogging itself, otherwise the effects wouldn't propagate between the servers.
One thing that occurred to me is that the receiving syslog server doesn't have routing back to these servers, so we never get any reply packets (if there are any), so syslog acts on a best-effort "fire and forget" way. Could this be a cause?
I'm running an authoritative nameserver for a reverse /16 zone, where every IP is mapped to a custom subdomain.
This is achieved by a zone file with 256 $GENERATE directives, for example (subnet 11.22.0.0/16):
$GENERATE 0-255 $.1 PTR $.1.22.11.rev.example.com.
$GENERATE 0-255 $.2 PTR $.2.22.11.rev.example.com.
(...)
This works fine, the only issue is that whenever we add a "meaningful" reverse record (4.3.22.11.in-addr.arpa. IN PTR www.example.com.) it will result in a situation where there are 2 PTR records for the same IP address:
4.3.22.11.in-addr.arpa. IN PTR www.example.com.
4.3.22.11.in-addr.arpa. IN PTR 4.3.22.11.rev.example.com.
For the most part this is fine, but in some cases we need to have a single PTR record.
The solution has been to "unroll" the $GENERATE block into individual PTR records and replace the offending one. Is there a way to override a generated record without having to expand the whole range?
This nameserver runs BIND 9.8.2 on RHEL6.
While investigating an issue afflicting a cluster of proxies which are all affected simultaneously, I've found weird behaviour in the establishment of SSL connections.
The symptom is that outgoing HTTPS requests are slower than usual when the impact occurs, I've pinned it down to slowness in finishing the SSL handshake. HTTP requests/connections are not affected in the same way.
The issue appears to be caused on outbound connections by a delay between the end of the TCP 3-way handshake and the sending of the Client Hello by the proxies. After that the handshake completes normally without delays.
Here are some examples from traffic captures:
To api.twitter.com (2.4 seconds delay):
To graph.facebook.com (28.4 seconds delay):
Even with the retransmissions in the second example, the Client Hello packet should not have taken that long to go out.
Some facts/considerations:
curl and openssl s_client connect, with the same resultsWhat needs clarification:
Software versions:
Edit: strace information
Did a few straces as recommended by an answer below, caught these slow calls:
strace -T -o output.strace openssl s_client -connect 104.244.42.66:443 </dev/null
connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.66")}, 16) = 0 <2.266597>
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}]) <2.387366>
write(3, "\26\3\1\0S\1\0\0O\3\1X\342\24\3556c\354\270T\302\225[\236\317\327\305\205r\177\t/"..., 88) = 88 <0.000034>
read(3, "\26\3\1\0001\2\0", 7) = 7 <2.556229>
read(3, "\0-\3\1\332\37\254+\240\320\236qA\375\275L\23l\340\355\205x\264\274\273\213\377\323&\345\307O"..., 47) = 47 <0.000011>
read(3, "\26\3\1\v\273", 5) = 5 <0.000007>
(...)
read(3, "\24\3\1\0\1", 5) = 5 <2.223115>
The poll() call is a reverse DNS lookup, it's doing:
sendto(4, "\3623\1\0\0\1\0\0\0\0\0\0\00266\00242\003244\003104\7in-ad"..., 44, MSG_NOSIGNAL, NULL, 0) = 44 <0.000157>
Other such poll() calls in the same trace are quick.
How can I make systemd treat calls to systemctl xx named as calls to systemctl xx named-chroot?
Under RHEL/CentOS 6 installing the bind-chroot package would set up a chroot'ed environment for BIND, but the control script would remain the same. i.e. a service named start would control the BIND process regardless if it were chroot'ed or not.
I'm migrating DNS servers to RHEL7, where named and named-chroot are now independent services. This can cause trouble for some operators who are not aware of the distinction and may think that BIND is down if they run systemctl status named instead of systemctl status named-chroot.
Is there a way to link the named control script to named-chroot under systemd so as to avoid the risk of confusion?
Is it possible to make apache (2.2) mod_proxy follow upstream redirects (http 301, 302)?
Usually one would configure a reverse proxy like:
ProxyPass /foo http://upstream.example.com/bar
ProxyPassReverse /foo http://upstream.example.com/bar
However, if upstream.example.com responds with a redirect, it is passed through for the client to follow.
Is it possible to make apache follow the redirect(s) until it gets a proper response and only then respond to the client?
I'm running apache as a forward proxy to do header injection, URL manipulation, and request logging for some Android apps and I'd need to override the destination for some requests.
For example, www.example.com would have an IP address of 1.2.3.4 but I need to divert the traffic to 4.3.2.1 without changing the application or affecting any other apps running on the apache server.
I'd also need the flexibility to override the address under different conditions, which means that manipulating /etc/hosts is not an option.
The clients are apps running on Android emulators which are configured to use apache proxy instances running on the host machine.
So far I have a setup like this:
## conf.d/proxy_a.conf
## proxy_b.conf, proxy_c.conf listen on different ports with different mappings / headers
Listen localhost:16002
<VirtualHost localhost:16002>
ProxyRequests On
ProxyPreserveHost On
RewriteEngine On
<Proxy "http://www.example.com/*">
Order deny,allow
Deny from all
Allow from localhost
RequestHeader set host "www.example.com"
RewriteRule ^/?(.*) http://4.3.2.1/$1 [NE]
</Proxy>
<Proxy *>
Order deny,allow
Deny from all
Allow from localhost
</Proxy>
## also tried, doesn't work
#RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
#RewriteRule ^/?(.*) http://4.3.2.1/$1 [NE]
RequestHeader set x-custom-header "abcdefgh"
RequestHeader merge user-agent "proxy16002"
</VirtualHost>
I'm aware that the functionality I'm looking for is easily achievable with a reverse proxy, but I'm looking for a solution using a straight proxy (no need to modify /etc/hosts or applications).
What's missing? Is this even possible with apache (2.2)?
After upgrading BIND to 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 in a few caching nameservers I've noticed it's doing lots of outgoing NS queries, without changes to incoming traffic volume or patterns.
As a result, the servers are consuming much more CPU and network bandwidth which has led to performance and capacity issues.
This did not happen with the previously installed version 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 or 9.8.2-0.30.rc1.el6_6.3 (the last version on CentOS 6.6), and I could see the change in the graphs matching the time of the upgrade.
The graphs are below, the brown band corresponds to NS queries. The breaks are due to the server restart after upgrading BIND.
incoming queries:
outgoing queries:
A tcpdump shows thousands of queries/sec asking for NS records for every queried hostname. This is odd, as I expected to see a NS query for the domain (example.com) and not the host (www.example.com).
16:19:42.299996 IP xxx.xxx.xxx.xxx.xxxxx > 198.143.63.105.53: 45429% [1au] NS? e2svi.x.incapdns.net. (49)
16:19:42.341638 IP xxx.xxx.xxx.xxx.xxxxx > 198.143.61.5.53: 53265% [1au] NS? e2svi.x.incapdns.net. (49)
16:19:42.348086 IP xxx.xxx.xxx.xxx.xxxxx > 173.245.59.125.53: 38336% [1au] NS? www.e-monsite.com. (46)
16:19:42.348503 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.195.166.53: 25752% [1au] NS? moneytapp-api-us-1554073412.us-east-1.elb.amazonaws.com. (84)
16:19:42.367043 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.194.120.53: 24002% [1au] NS? LB-lomadee-adservernew-678401945.sa-east-1.elb.amazonaws.com. (89)
16:19:42.386563 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.194.227.53: 40756% [1au] NS? ttd-euwest-match-adsrvr-org-139334178.eu-west-1.elb.amazonaws.com. (94)
tcpdump of a client's request shows:
## client query
17:30:05.862522 IP <client> > <my_server>.53: 1616+ A? cid-29e117ccda70ff3b.users.storage.live.com. (61)
## recursive resolution (OK)
17:30:05.866190 IP <my_server> > 134.170.107.24.53: 64819% [1au] A? cid-29e117ccda70ff3b.users.storage.live.com. (72)
17:30:05.975450 IP 134.170.107.24.53 > <my_server>: 64819*- 1/0/1 A 134.170.111.24 (88)
## garbage NS queries
17:30:05.984892 IP <my_server> > 134.170.107.96.53: 7145% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
17:30:06.105388 IP 134.170.107.96.53 > <my_server>: 7145- 0/1/1 (158)
17:30:06.105727 IP <my_server> > 134.170.107.72.53: 36798% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
17:30:06.215747 IP 134.170.107.72.53 > <my_server>: 36798- 0/1/1 (158)
17:30:06.218575 IP <my_server> > 134.170.107.48.53: 55216% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
17:30:06.323909 IP 134.170.107.48.53 > <my_server>: 55216- 0/1/1 (158)
17:30:06.324969 IP <my_server> > 134.170.107.24.53: 53057% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
17:30:06.436166 IP 134.170.107.24.53 > <my_server>: 53057- 0/1/1 (158)
## response to client (OK)
17:30:06.438420 IP <my_server>.53 > <client>: 1616 1/1/4 A 134.170.111.24 (188)
I thought this could be a cache population issue, but it did not subside even after the server has been running for a week.
Some details:
ROOTDIR=/var/named/chroot ; OPTIONS="-4 -n4 -S 8096"named.conf contents belowWhat is going on here? Is there a way to change the configuration to avoid this behaviour?
acl xfer {
(snip)
};
acl bogusnets {
0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
};
acl clients {
(snip)
};
acl privatenets {
127.0.0.0/24; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};
acl ops {
(snip)
};
acl monitoring {
(snip)
};
include "/etc/named.root.key";
key rndckey {
algorithm hmac-md5;
secret (snip);
};
key "monitor" {
algorithm hmac-md5;
secret (snip);
};
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; };
inet (snip) allow { monitoring; } keys { monitor; }; };
logging {
channel default_syslog { syslog local6; };
category lame-servers { null; };
channel update_debug {
file "/var/log/named-update-debug.log";
severity debug 3;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/named-auth.info";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel querylog{
file "/var/log/named-querylog" versions 3 size 10m;
severity info;
print-category yes;
print-time yes;
};
category queries { querylog; };
category update { update_debug; };
category security { security_info; };
category query-errors { security_info; };
};
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
statistics-file "/var/named/named.stats";
dump-file "/var/named/named_dump.db";
zone-statistics yes;
version "Not disclosed";
listen-on-v6 { any; };
allow-query { clients; privatenets; };
recursion yes; // default
allow-recursion { clients; privatenets; };
allow-query-cache { clients; privatenets; };
recursive-clients 10000;
resolver-query-timeout 5;
dnssec-validation no;
querylog no;
allow-transfer { xfer; };
transfer-format many-answers;
max-transfer-time-in 10;
notify yes; // default
blackhole { bogusnets; };
response-policy {
zone "rpz";
zone "netrpz";
};
};
include "/etc/named.rfc1912.zones";
include "/etc/named.zones";
statistics-channels { inet (snip) port 8053 allow { ops; }; inet 127.0.0.1 port 8053 allow { 127.0.0.1; }; };
zone "rpz" { type slave; file "slaves/rpz"; masters { (snip) }; };
zone "netrpz" { type slave; file "slaves/netrpz"; masters { (snip) }; };
I'm using webmin to manage BIND DNS zones which until now have been managed manually.
When I add a new record in webmin (A or CNAME) it's writing the FQDN (host + zone) into the zone file. While this is not breaking anything, it's adding a lot of unnecessary text to the already huge zone file.
Example:
# /var/named/master/some.zone.com
# manually-added record
somehost01 IN A 10.10.10.1
# added via webmin
somehost02.some.zone.com. IN A 10.10.10.2
Is there a way to configure webmin to not write the FQDN when a record is added to a master zone?
I'm building a test cluster using centos7 and pacemaker, with shared storage on GFS2 over clustered LVM.
I've set up a 2-node cluster, dlm and clvmd, both nodes can see the clustered logical volumes. Fencing is disabled for this cluster.
However, when I try to format the clustered logical volume as GFS2, the operation fails silently and no filesystem is created on it.
The output of mkfs (I created an ext4 filesystem on the logical volume previously to check if it was accessible):
[root@rsfe2 ~]# mkfs -t gfs2 -p lock_dlm -j 2 -t fecluster:cluster_lv_gfs /dev/cluster_vg_gfs/cluster_lv_gfs ; echo $?
It appears to contain an existing filesystem (ext4)
/dev/cluster_vg_gfs/cluster_lv_gfs is a symbolic link to /dev/dm-2
This will destroy any data on /dev/dm-2
Are you sure you want to proceed? [y/n]y
### a long time elapses...
1
Output of pcs status:
[root@rsfe1 ~]# pcs status
Cluster name: fecluster
Last updated: Thu Nov 6 15:32:13 2014
Last change: Thu Nov 6 15:31:08 2014 via crmd on rsfe2.int
Stack: corosync
Current DC: rsfe1.int (1) - partition with quorum
Version: 1.1.10-32.el7_0.1-368c726
2 Nodes configured
4 Resources configured
Online: [ rsfe1.int rsfe2.int ]
Full list of resources:
Clone Set: dlm-clone [dlm]
Started: [ rsfe1.int rsfe2.int ]
Clone Set: clvmd-clone [clvmd]
Started: [ rsfe1.int rsfe2.int ]
PCSD Status:
rsfe1.int: Online
rsfe2.int: Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Versions:
[root@rsfe2 ~]# uname -a
Linux rsfe2 3.10.0-123.9.2.el7.x86_64 #1 SMP Tue Oct 28 18:05:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@rsfe1 ~]# rpm -qa | egrep "pcs|pacemaker|corosync|clvmd|dlm|gfs"
corosync-2.3.3-2.el7.x86_64
pcs-0.9.115-32.el7.x86_64
dlm-4.0.2-3.el7.x86_64
pacemaker-libs-1.1.10-32.el7_0.1.x86_64
pacemaker-cluster-libs-1.1.10-32.el7_0.1.x86_64
pacemaker-cli-1.1.10-32.el7_0.1.x86_64
gfs2-utils-3.1.6-13.el7.x86_64
corosynclib-2.3.3-2.el7.x86_64
pacemaker-1.1.10-32.el7_0.1.x86_64
dlm-lib-4.0.2-3.el7.x86_64
What am I missing here?
I'm building a proof-of-concept loadbalancer with CentOS 7 and keepalived.
I took Red Hat's load balancer administration guide as a reference and implemented a NAT'ed loadbalancer with 2 nodes which carries traffic between a public and a private network. To that effect, the loadbalancer has 2 VIPs: one for client traffic, on the public network; and one for ensuring failover for response traffic, on the private network.
The 2 loadbalancers (lb1 and lb2) are sending traffic to 2 hosts running apache (fe1 and fe2) on the internal network. lb1 is master, lb2 is backup.
Diagram is as follows:
The loadbalancer works, and fails over as expected when one of the directors goes down.
What is bugging me is that the incoming traffic on the real servers isn't coming from the internal VIP (10.10.33.254), but from the loadbalancer hosts' real addresses (10.10.33.2 and 10.10.33.3). Ping from the real servers is also going through real IP addresses, and not the internal VIP, despite it being set as the default gateway for them.
Traceroute (lb1 as active):
[root@rsfe2 ~]# tracepath www.google.com
1: rsfe2 0.081ms pmtu 1500
1: 10.10.33.2 0.385ms
1: 10.10.33.2 0.385ms
2: no reply
3: 192.168.1.1 1.552ms
(lb1 down, lb2 as active):
[root@rsfe2 ~]# tracepath www.google.com
1: rsfe2 0.065ms pmtu 1500
1: 10.10.33.3 0.463ms
1: 10.10.33.3 0.462ms
2: no reply
3: 192.168.1.1 2.394ms
Routing table:
[root@rsfe2 ~]# ip route
default via 10.10.33.254 dev enp0s8 proto static metric 1024
10.10.33.0/24 dev enp0s8 proto kernel scope link src 10.10.33.12
Despite this apparent anomaly, failover from one loadbalancer to the other works as expected from the clients' standpoint, seemingly due to the gratuitous ARPs from the surviving loadbalancer.
It seems that the internal VIP is not used for anything except ARP announcements, in the end (there is no traffic to or from it).
Should I be concerned about this, or is it working as expected?
My keepalived.conf contents:
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
router_id LVS_DEVEL
}
vrrp_sync_group VG1 {
group {
RH_EXT
RH_INT
}
}
vrrp_script check_haproxy {
script "/bin/pkill -0 -F /var/run/haproxy.pid"
interval 1
fall 1
rise 5
}
vrrp_instance RH_EXT {
state MASTER
interface enp0s3
virtual_router_id 50
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
192.168.10.80
}
track_script {
check_haproxy
}
track_interface {
enp0s3
}
}
vrrp_instance RH_INT {
state MASTER
interface enp0s8
virtual_router_id 2
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
10.10.33.254
}
track_script {
check_haproxy
}
track_interface {
enp0s8
}
}
virtual_server 192.168.10.80 80 {
lb_algo rr
lb_kind NAT
real_server 10.10.33.11 80 {
HTTP_GET {
url {
path /check.html
}
}
}
real_server 10.10.33.12 80 {
HTTP_GET {
url {
path /check.html
}
}
}
}