diff --git a/rsyslog-7.4.7-bz1030044-remove-ads.patch b/rsyslog-7.4.7-bz1030044-remove-ads.patch
deleted file mode 100644
index cdbcf0e..0000000
--- a/rsyslog-7.4.7-bz1030044-remove-ads.patch
+++ /dev/null
@@ -1,236 +0,0 @@
-From 79e4e43bcadb0fb520240c655f529874f305f786 Mon Sep 17 00:00:00 2001
-From: Tomas Heinrich
Our secrity goals are achived via public/private key security. As such, it is - vital that private keys are well protected and not accessible to third parties. -- -- -- -- - If private keys have become known to third parties, the system does not provide - any security at all. Also, our solution bases on X.509 certificates and a (very - limited) chain of trust. We have one instance (the CA) that issues all machine -diff --git a/doc/tls_cert_ca.html b/doc/tls_cert_ca.html -index 2cae404..f366462 100644 ---- a/doc/tls_cert_ca.html -+++ b/doc/tls_cert_ca.html -@@ -23,19 +23,6 @@ Gerhards (2008-06-17)
- maintained by a trustworthy person (or group) and approves the indentities of - all machines. It does so by issuing their certificates. In a small setup, the - administrator can provide the CA function. What is important is the the CA's -- -- -- -- - private key is well-protocted and machine certificates are only issued if it is - know they are valid (in a single-admin case that means the admin should not - issue certificates to anyone else except himself). -diff --git a/doc/tls_cert_client.html b/doc/tls_cert_client.html -index dbe7961..53596fc 100644 ---- a/doc/tls_cert_client.html -+++ b/doc/tls_cert_client.html -@@ -25,19 +25,6 @@ example, that meanst turng.example.net). The client check's the server's identit - talks to it only if it is the expected server. This is a very important step. - Without it, you would not detect man-in-the-middle attacks or simple malicious servers - who try to get hold of your valuable log data. -- -- -- -- -Steps to do: -
This page covers error message you may see when setting up -- -- -- -- - rsyslog with TLS. Please note that many - of the message stem back to the TLS library being used. In those cases, there is - not always a good explanation available in rsyslog alone. -diff --git a/doc/tls_cert_machine.html b/doc/tls_cert_machine.html -index 095e15c..fe2ee90 100644 ---- a/doc/tls_cert_machine.html -+++ b/doc/tls_cert_machine.html -@@ -22,19 +22,6 @@ Gerhards (2008-06-18)
-In this step, we generate certificates for each of the machines. Please note - that both clients and servers need certificates. The certificate identifies each - machine to the remote peer. The DNSName specified inside the certificate can -- -- -- -- - be specified inside the $<object>PermittedPeer config statements. -
For now, we assume that a single person (or group) is responsible for the whole - rsyslog system and thus it is OK if that single person is in posession of all -diff --git a/doc/tls_cert_scenario.html b/doc/tls_cert_scenario.html -index 7973532..88c7657 100644 ---- a/doc/tls_cert_scenario.html -+++ b/doc/tls_cert_scenario.html -@@ -21,19 +21,6 @@ Gerhards (2008-06-17)
- -We have a quite simple scenario. There is one central syslog server, -- -- -- -- - named central.example.net. These server is being reported to by two Linux - machines with name zuse.example.net and turing.example.net. Also, there is a - third client - ada.example.net - which send both its own messages to the central -diff --git a/doc/tls_cert_server.html b/doc/tls_cert_server.html -index 9c024bc..b784be1 100644 ---- a/doc/tls_cert_server.html -+++ b/doc/tls_cert_server.html -@@ -23,19 +23,6 @@ Gerhards (2008-06-18)
- via TLS protected plain tcp based syslog from those peers that are explicitely permitted - to send to it. The picture below show our configuration. This step configures - the server central.example.net. -- -- -- -- -Important: Keep in mind that the order of configuration directives - is very important in rsyslog. As such, the samples given below do only work if the given -diff --git a/doc/tls_cert_summary.html b/doc/tls_cert_summary.html -index 8e003bc..95844a8 100644 ---- a/doc/tls_cert_summary.html -+++ b/doc/tls_cert_summary.html -@@ -20,19 +20,6 @@ Gerhards (2008-07-03)
- -If you followed the steps outlined in this documentation set, you now have -- -- -- -- - a reasonable (for most needs) secure setup for the following environment: -
You have learned about the security decisions involved and which we -diff --git a/doc/tls_cert_udp_relay.html b/doc/tls_cert_udp_relay.html -index f4740ce..d44689c 100644 ---- a/doc/tls_cert_udp_relay.html -+++ b/doc/tls_cert_udp_relay.html -@@ -26,19 +26,6 @@ directly to it, because we would like to have TLS protection for its sensitve - logs. If the router and the syslog relay are on a sufficiently secure private - network, this setup can be considered reasonable secure. In any case, it is the - best alternative among the possible configuration scenarios. -- -- -- -- -
Steps to do: -