Docker message: Automatically disabled Acquire::http::Pipeline-Depth due to incorrect response from server/proxy - apache

Installing apache2 into a Ubuntu 16.04 image of Docker , I am getting the follow message
W: http://archive.ubuntu.com/ubuntu/pool/main/g/gdbm/libgdbm3_1.8.3-13.1_amd64.deb: Automatically disabled Acquire::http::Pipeline-Depth due to incorrect response from server/proxy. (man 5 apt.conf).
That is the Dockerfile:
FROM ubuntu:16.04
#RUN apt-get update
#https://github.com/phusion/baseimage-docker/issues/319
RUN apt-get update && apt-get install -y --no-install-recommends apt-utils
RUN apt-get install -y apache2
When I open the image I see the /var/www/html folder, meaning, the apache was installed.
What message is that? Is it an error or can I consider apache as fully installed?

Pipelining is a feature of the HTTP/1.1 protocol. From the RFC 7230 :
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but it MUST send the corresponding responses in the same order that
the requests were received.
This feature can be activated in apt with the setting Acquire::http::Pipeline-Depth. From man apt.conf:
The setting Acquire::http::Pipeline-Depth can be used to enable HTTP pipelining (RFC 2616 section 8.1.2.2) which can be beneficial e.g. on high-latency connections. It specifies how many requests are sent in a pipeline. APT tries to detect and workaround misbehaving webservers and proxies at runtime, but if you know that yours does not conform to the HTTP/1.1 specification pipelining can be disabled by setting the value to 0. It is enabled by default with the value 10.
The message you see means that your connection with the apt repository doesn't support pipelining, (probably because of some kind of proxy) and that this feature was automatically disabled by apt. The installation will maybe takes a bit more time but you can consider your apache server fully installed.

Related

Webmin send fatal error when i try to satart ProFTPD Server

I'm trying to start ProFTPD Server but i recieve the next message:
Starting proftpd (via systemctl): proftpd.serviceJob for proftpd.service failed because the control process exited with error code.
See "systemctl status proftpd.service" and "journalctl -xe" for details.
failed!
And when i get more information about it, i have:
fatal: TLSRSACertificateFile. '/etc/ssl/certs/proftp.crt' does not exists on line 8 '/etc/proftpd/conf.d/virtualmin.conf/'
I have to say i did'nt installed ProFTPD Server because this module came with the webmin installation.
Hope you can help me to know why proftp.crt fie does not exists and how can i fix this issue.
Thanks.
Don't know Webmin (I used it once approximalety 20 years ago..) but there should at least be options to disable TLS for the FTP Server and to change the path to the certificate if it is able to manage ProFTPD for You.
Other alternative (better then turning SSL/TLS off): copy Your cert for the server there (you have to do something similiar for the key I assume), if You do not have one You can get one or create Your own self-signed (not sure whether Webin can help You with that, but on command line it's pretty simple to create one with openssl.)
Come on...
1 - Check if your plugin is active in VirtualMin.
1.1 - Shell check if your SFTP is installed
== ProFTPD install
UBUNTU = apt install proftpd -y
CENTOS = yum install proftpd -y
2 - Check if your domain is SFTP enabled.
3 - Create an SSL within the domain, after created click on the option to use SSL for SFTP.
VIRTUALMIN // Domain >> Server Configuration >> SSL
4 - Create an SSL for the domain you use to access WebMin.
E Use this SSL for WebMin // VirtualMIn
5 - Check the proftpd settings via WEBMIN.
Good luck! Send news about your progress ...

outbound connections (curl, sockets) not working for apache but working as root

After a recent automatic update to linux components (CentOS v7 with PLesk 17.8.11) my web (php) applications are no longer enabled to do outbound connections.
Both "curl" requests and PHPMailer fail; curl is returning http code 0 with no content, while PHPMailer says "SMTP Connect() failed".
The same statements/programs work perfectly when run from terminal (root user). In other words, if I write a trivial program executing "curl http://www.example.com" and run it from terminal, it works; if I call it from a browser, it does not work.
The same is true for any program using PHPMailer to send a mail.
SELinux is disabled, so it does not depends on the httpd_can_network_connect SELinux boolean.
Any idea?
I found a solution, but I did not really understood what the real reason was. By default, my CentOS+Plesk server has SELinux disabled: I changed it to "enabled" with SELINUX=permissive, then I changed two SELinux booleans:
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_sendmail on
Even if SELinux is in warning-only mode, settings those two booleans on made the trick.
Most likely, affected domains are using system PHP, which was updated recently. Correct me if I am wrong.
What would explain broken PHP functionality, because during the update of system PHP package, Apache restart is not triggered by Plesk.
Simply restart Apache in Tools & Settings > Service Management or by using systemctl restart httpd. If the issue still persist after that, try to switch to any of Plesk PHP versions.

Installing apache as a "manual" service (service that must not start automatically during the boot process)

I am trying to install Apache as a manual service as I don't want it to start automatically during the boot process.
When Apache is installed as a service by httpd -k install -n "apache_2.x", it starts automatically during the boot process which is not required. Like MariaDB/MySQL can be installed as a manual service by mysqld --install-manual "mariadb_10.x", can someone tell me how you install Apache as a manual service?
I also found out that Apache takes an argument called config as httpd -k config which is said to "change startup Options of an Apache service" (as quoted in httpd -h). I speculate that this option can help change the startup behavior. Can someone also please enlighten me on this argument?
Thanks in advance.

Unable to register host while creating Apache Ambari cluster

I am trying to create localhost Apache Ambari cluster on CentOS7. I am using Ambari 2.2.2 binaries downloaded and installed from the Ambari repository with the following commands
cd /etc/yum.repos.d/
wget http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.2.2.0/ambari.repo
yum install ambari-server
ambari-server setup
ambari-server start
Before starting the server I have done all the necessary preparations steps described on the Hortonworks including the setup of passwordless ssh, which is frequent reason of problems according to the posts found on the internet. I verify it with
ssh root#localhost
During the creation of cluster in the "Install options" window I enter the name of the host I want to create (localhost in my case) and have already tried both of the options, which are
providing rsa secret key direktly - in this case the next window
simply stucks in the "Installing" stage and does not go any further,
showing no errors
performing manual registration of hosts.
For the second option I have downloaded and installed ambari-agent
yum install ambari-agent
ambari-agent start
In case of manual host registration I am getting the following error
"Host checks were skipped on 1 hosts that failed to register.".
When I click on "Failed", which in some cases described over the internet is supposed to deliver more precise description of a problem I see the following
"Registering with the server...
Registration with the server failed."
As a result I don't even now where to start searching for the possible reasons of this error.
Ambari cluster nodes need to be configured with a Fully Qualified Domain Name (FQDN). localhost is not an FQDN. You will need to configure the node with an FQDN and then retry the installation. You could use something like: localhost.local which is an FQDN. This requirement and how to configure the node to meet it are documented in the pre-requirements. From the HDP documentation:
All hosts in your system must be configured for both forward and and reverse DNS.
If you are unable to configure DNS in this way, you should edit the /etc/hosts file on every host in your cluster to contain the IP address and Fully Qualified Domain Name of each of your hosts.
I had the same "Registering with the server... Registration with the server failed." problem just recently.
I found the response on the same topic recommending to take a look at the log file which is located here /var/log/ambari-agent/ambari-agent.log from there was able to check that the hostname was set up incorrectly during some other phase of installation (I had it something like ambari.hadoop instead of localhost). So I went to the /etc/ambari-agent/conf/ambari-agent.ini and fixed it there.
I know that I'm digging some quite old question, but seems that compiling all that at one place might help someone with the same problem.

Apache restart failed after adding OpenID Connect module

I use Debian 8.0 running an Apache v.2.4.10 and I try to add the OpenID Connect module named libapach2-mod-auth-openidc version 1.6.0.
After installing the module, I enable it with the command: sudo a2enmod auth_openidc. This works fine and now I want to restart the Apache server with sudo service apache2 restart, which leads me to an error
"Job for apache2 failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details."
The result of
systemctl status apache2.service
shows an error while starting the server, but no detailed information of the error (code=exited, status=1/FAILURE).
And the result of
journalctl -xn
tells, that there are no journals.
So if I am disabling the auth_openidc module, the Apache server starts again without problems.
Details of the Configuration:
Apache runs with its default settings. I did not change anything!
auth_openidc module was not changed by me neither at this time!
Can someone explain why Apache with the enabled auth_openidc module would not start anymore?
After installing libapache2-mod-auth-openidc you will have to configure some settings before the module can be used successfully. Two of the mandatory settings are OIDCRedirectURI and OIDCCryptoPassphrase. Most probably you'll also have to configure client credentials for your OpenID Connect provider. You can take a look at the sample configurations at: https://github.com/pingidentity/mod_auth_openidc#openid-connect-sso-with-google-sign-in
Errors/warnings about the missing configuration directives should be displayed in: /var/log/apache2/error.log
While we're at it, I would also advise you to use the latest version 1.8.1 from https://github.com/pingidentity/mod_auth_openidc/releases