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 ...
Related
Thanks you for taking the time out for helping. I am facing an issue with my apache server and the story goes like this:
I was running an ubuntu 18.04 server and my SSL(letsencrypt ssl obtained through certbot) got expired when I ran the command : certbot renew but it gave me errors relating to DNS. Then I thought it would be a good idea if I simply delete the existing certificate and install a new one so I googled how to delete a ssl certificate using certbot and got to know about sudo certbot delete but it didn't worked as expected and when I restarted the server apache didn't started and when I ran the command apache2ctl configtest it returned an error saying :
AH00526: Syntax error on line 20 of /etc/apache2/sites-enabled/000-default-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/tomebox.in/fullchain.pem' does not exist or is empty
Action 'configtest' failed.
The Apache error log may have more information.
Can anyone please help me understanding and resolving the issue and getting my website back to normal.
You'll need to edit the etc/apache2/sites-enabled/000-default-le-ssl.conf file to change the file being referenced, as you have deleted that file. You can create a new certificate to reference using certbot instructions, or delete 000-default-le-ssl.conf altogether if you are no longer using SSL.
To edit the file, navigate to the directory in SSH using
cd etc/apache2/sites-enabled/
and then edit the file as root using
sudo nano 000-default-le-ssl.conf
ctrl+ x will exit and give option to save when done. You may want to restart apache2 after:
sudo service apache2 restart
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.
I have a VPS setup with Centos 6, with the new Apple requirements for HTTPS access I was looking at using Certbot. Now the problem is I go through the setup process and the following error pops up
The apache plugin is not working; there may be problems with your
existing configuration. The error was: NoInstallationError('Cannot
find Apache control command apachectl',)
When I run the following
find / -name apachectl
I get
/home/cpeasyapache/src/httpd-2.4/support/apachectl
/usr/local/apache.backup/bin/apachectl /usr/local/apache/bin/apachectl
Is there a way I can alter the config so that the system can use apachectl. The system came pre-built from UK2.
Thanks
I've been trying off and on to get a LAMP development server operational behind my corporate firewall (McAfee Web Gateway). I have a Ubuntu/Trusty64 image on a virtualbox VM provisioned through Vagrant. I cannot get "some" {most} repositories to load for a proper sudo apt-get update. I'm getting a 401 authentication required error on all 'security.ubuntu.com trusty-security/*' sources and 'archive.ubuntu.com trusty/*' sources and all fail to fetch. Therefore most all sudo apt-get install {whatever} fails and I cannot add the necessary PPA repository to install the LAMP environment I want.
I can turn off SSL verification for some things and can get many things installed - but I need SSL working correctly within this environment.
Digging deeper, I find that if I curl -v https://url.com:443, I get the
curl(60): ssl certificate error: unable to get local issuer certificate.
I have the generic bundle 'ca-bundle.crt' installed locally in /usr/local/share/ca-certificates/ and ran sudo update-ca-certificates which seemed to update ca-certificates.crt in etc/ssl/certs/.
I ran a strace -o stracker.out curl -v https://url.com:443 and searched for the failing stat() as suggested in here by No-Bugs_Hare and found that curl was looking for 'c099e901.0' in /etc/ssl/certs/ and it isn't there. Googling that particular HEXID is no joy and am stuck at this step.
Next I tried strace -o traceOppenSSL.out openssl s_client -connect url.com:443 to see if I can get more detail but can't see what causes the
verify error:num=20:unable to get local issuer certificate
followed by two other errors (I'm sure all relating to the first one), then displays the "Server Certificate" within a BEGIN / END block, followed by a bunch of other metadata. The entire session ends with
Verify return code: 21 (unable to verify the first certificate).
So, this is not my forte and I'm doing what I can to try and get this VM operational. Like I said earlier, I've been trying many things and understand most of the issue is the fact that I'm behind a McAfee firewall within my corporate structure. I don't know how to troubleshoot more than what I've explained above but I'm willing to dig deeper.
I have a few questions. Why is curl looking for that particular hex ID and where would I find or generate the beast? Are there other troubleshooting steps I should try? The VM is a server-class Ubuntu install, so I only have a SSH CLI terminal and no WindowManager GUI to work with this.
I'm using TortoiseHG on win7 64b to clone repository using https protocol. I've installed and configured the public cert on my side so the validity of server cert can be checked.
However, i'm having the following error when trying to clone:
% hg clone --verbose -- https://***/hg/Trainings/train-repo1 "c:\sandboxes\hg"
SSL error: wrong version number
[command returned code 255 Wed Nov 06 14:28:47 2013]
I guess I have to configure the SSL version supported on Tortoise side somehow, but cannot find resources on internet about how to do. I'm looking for any explanation or documentation on the subject. Tks !
Note: the repo server force me to use https, and I have no control over it. (cannot switch to ssh)
I had a similar error message on an installation that had previously working without issue and no known changes to the server (which is under my control) or my local TortoiseHg install.
I tracked it down to having set the environment variables HTTP_PROXY and HTTPS_PROXY for an unrelated program on my computer.
I fixed it by adding the following to mercurial.ini:
[http_proxy]
host = <proxy-server>
no = <mercurial host ip address>
To fix this, I just updated TortoiseHG (via web or choco install tortoisehg), which in turn updated it's internal version of SSL, which I presume was so old bitbucket retired it.