https://wiki.koozali.org/api.php?action=feedcontributions&user=Mercyh&feedformat=atom
SME Server - User contributions [en]
2024-03-29T12:19:45Z
User contributions
MediaWiki 1.35.5
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33548
Letsencrypt
2017-06-13T15:16:55Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
Thanks to MSmith for the following forum thread.<br />
<br />
https://forums.contribs.org/index.php/topic,53052.0.html<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it.<br />
<br />
'''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see,<br />
<br />
'''FIRST READ ABOVE WARNING'''<br />
<br />
then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
<br />
https://forums.contribs.org/index.php/topic,53147.0.html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33547
Letsencrypt
2017-06-13T13:07:10Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
Thanks to MSmith for the following forum thread.<br />
<br />
https://forums.contribs.org/index.php/topic,53052.0.html<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
<br />
https://forums.contribs.org/index.php/topic,53147.0.html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33546
Letsencrypt
2017-06-13T13:04:55Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
<br />
https://forums.contribs.org/index.php/topic,53147.0.html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33545
Letsencrypt
2017-06-13T13:04:34Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
https://forums.contribs.org/index.php/topic,53147.0.html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33544
Letsencrypt
2017-06-13T04:20:05Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33543
Letsencrypt
2017-06-13T04:11:17Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
rerun<br />
dehydrated -c<br />
<br />
and your challenges should complete.<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33542
Letsencrypt
2017-06-13T04:09:43Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33541
Letsencrypt
2017-06-13T04:09:18Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
db hosts setprop mail.domain1.com letsencryptSSLcert enabled<br />
etc. until all the public facing hostnames are enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33540
Letsencrypt
2017-06-13T04:07:05Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. <br />
<br />
Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33539
Letsencrypt
2017-06-13T04:05:49Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
If this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see, '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33538
Letsencrypt
2017-06-13T04:03:19Z
<p>Mercyh: /* Challenge fails with unauthorized 403 error */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''<br />
<br />
use the following to check the rights:<br />
cd /home/e-smith/files/ibays<br />
then<br />
ls -l<br />
on my test server with only the Primary ibay I get the following:<br />
total 4<br />
drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary<br />
<br />
IF this is not what you see, you need to correct it. '''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''<br />
From within ''/home/e-smith/files/ibays/'' issue the following:<br />
chown root:root Primary<br />
If the rights are not correct, issue:<br />
chmod 0755 Primary<br />
<br />
Next check the html directory.<br />
cd /home/e-smith/files/ibays/Primary<br />
then<br />
ls -l<br />
on my test server I have the following<br />
[root@backupserver Primary]# ls -l<br />
total 12<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin<br />
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files<br />
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''<br />
<br />
If this is not what you see '''FIRST READ ABOVE WARNING''' then adjust as follows<br />
chown admin:shared html<br />
If the rights are not correct, issue: <br />
chmod 2750 html<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33537
Letsencrypt
2017-06-13T03:33:20Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
====Challenge fails with unauthorized 403 error====<br />
<br />
If your challenge returns something like the following:<br />
ERROR: Challenge is invalid! (returned: invalid) (result: {<br />
"type": "http-01",<br />
"status": "invalid",<br />
"error": {<br />
"type": "urn:acme:error:unauthorized",<br />
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text><br />
"status": 403<br />
and your ''httpd error_log'' on your server shows something like this:<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33536
Letsencrypt
2017-06-13T03:26:49Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33535
Letsencrypt
2017-06-13T03:25:12Z
<p>Mercyh: /* Hosts and domains for the certificate */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33534
Letsencrypt
2017-06-13T03:21:35Z
<p>Mercyh: /* Some challenges complete successfully but some hostnames fail */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
====Some challenges complete successfully but some hostnames fail====<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33533
Letsencrypt
2017-06-13T03:21:09Z
<p>Mercyh: /* rateLimited, Too many currently pending Authorizations */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
====rateLimited, Too many currently pending Authorizations====<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
==Some challenges complete successfully but some hostnames fail==<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33532
Letsencrypt
2017-06-13T03:20:52Z
<p>Mercyh: /* Errors */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
====No registration exists matching provided key====<br />
<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
==rateLimited, Too many currently pending Authorizations==<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
<br />
<br />
==Some challenges complete successfully but some hostnames fail==<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33531
Letsencrypt
2017-06-13T03:19:44Z
<p>Mercyh: /* Errors */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
==No registration exists matching provided key=='<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
<br />
<br />
==rateLimited, Too many currently pending Authorizations==<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
<br />
<br />
==Some challenges complete successfully but some hostnames fail==<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33530
Letsencrypt
2017-06-13T03:17:40Z
<p>Mercyh: /* Errors */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
<br />
<br />
'''* No registration exists matching provided key'''<br />
<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
<br />
<br />
'''* rateLimited, Too many currently pending Authorizations'''<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
<br />
<br />
'''* Some challenges complete successfully but some hostnames fail'''<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A or MX records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33529
Letsencrypt
2017-06-13T03:05:13Z
<p>Mercyh: /* Errors */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
==========<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
==========<br />
<br />
If you see some of your challenges returned without error but some fail, you need to make sure that you have Public DNS A records for all the host names that you are adding to your certificate. Using the command:<br />
config setprop letsencrypt configure all<br />
<br />
Is likely to cause this to happen. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.<br />
<br />
To resolve this, issue the following command:<br />
config setprop letsencrypt configure none<br />
<br />
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
and for each hostname:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
followed by:<br />
signal-event console-save<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Letsencrypt&diff=33528
Letsencrypt
2017-06-13T02:33:44Z
<p>Mercyh: /* Hosts and domains for the certificate */</p>
<hr />
<div>{{Level|Medium}}<br />
==Introduction==<br />
[https://letsencrypt.org/ Let’s Encrypt] is a new Certificate Authority: <br />
It’s free, automated, and open. Its main purpose is to allow people to encrypt their internet traffic at no cost, easily, and automatically. The certs delivered must be renewed every 3 months.<br />
<br />
As of December 2015, the Letsencrypt service is in a public beta state. They issue valid, trusted certificates, but the client code (and, to a lesser extent, the server code) is likely in a state of flux. At least during the initial stages of the public beta, they're implementing rate-limiting, allowing no more than five certificates per domain in a rolling seven-day period. This may make them unsuitable for users of dynamic DNS services. The latest information about rate limiting should be posted on [https://letsencrypt.org/docs/rate-limits/ this page] of the letsencrypt.org documentation. As of March 26, 2016, the rate limit has been increased to 20 certificates per domain per week.<br />
<br />
If you're going to be testing things in ways that would involve requesting lots of certificates in a short period of time, you're encouraged to use the Letsencrypt staging CA for this purpose. Certificates generated by this CA will not be trusted by your browser, and will appear to be issued by the "Fake LE Intermediate X1", but it will allow you to validate the toolchain and workflow.<br />
<br />
The current status of the Letsencrypt services can be found on their [https://letsencrypt.status.io/ status page].<br />
<br />
Multiple clients are available for the Letsencrypt services. The official "certbot" client from letsencrypt.org is quite full-featured, but has a number of dependencies that it needs to install. It also requires a newer version of Python than is included with a standard SME Server installation. Due to this complexity, and the lack of compatibility with SME 8.x, this document describes installation and use of ''[https://github.com/lukas2511/dehydrated dehydrated]'', an alternative client implemented as a BASH shell script.<br />
<br />
=== Version ===<br />
{{ #smeversion:smeserver-letsencrypt }}<br />
<br><br />
{{ #smeversion:dehydrated }}<br />
<br><br />
<br />
==Prerequisites==<br />
The Letsencrypt client and server interact to confirm that the person requesting a certificate for a hostname actually controls that host. For this reason, there are some prerequisites for your configuration. For example, if you're trying to obtain a certificate for www.example.com, the following conditions must be met:<br />
<br />
* www.example.com is a valid domain name--the domain has been registered, and DNS records are published for it.<br />
* www.example.com resolves to your SME Server--published DNS records give the external IP address of your SME Server when queried for www.example.com.<br />
* Your SME Server is connected to the Internet, and is able to make outbound connections on ports 80 and 443.<br />
* Port 80 on your SME Server is open to the Internet (i.e., the Internet can reach your server on port 80)--you aren't behind a firewall, or some ISP filtering, that would block it. If you've made SSL mandatory for the Primary ibay, port 443 must also be open.<br />
<br />
Letsencrypt will issue certificates that include multiple hostnames (for example, www.example.com, example.com, and mail.example.com), all of which would be part of the request. All of the conditions above must be true for all of the hostnames you want to include in the certificate.<br />
<br />
Make sure you've got this all set up correctly before continuing.<br />
<br />
==Preparation==<br />
<br />
Before you begin installation, check to see if you or an installed contrib have configured any custom values for your TLS/SSL certificate:<br />
# config show modSSL<br />
By default it would show:<br />
modSSL=service<br />
TCPPort=443<br />
access=public<br />
status=enabled<br />
<br />
If this shows any values for crt, key, or CertificateChainFile, make a note of them. If you encounter an issue with the certificate files generated by Letsencrypt, you'll then be able to revert your changes. To make a 'backup' of your existing key and properties you can issue:<br />
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"<br />
<br />
==Contrib Installation of Dehydrated==<br />
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.<br />
<br />
===Installation===<br />
yum install smeserver-letsencrypt --enablerepo=smecontribs<br />
<br />
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.<br />
<br />
===Updates===<br />
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:<br />
<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
signal-event console-save<br />
<br />
===Updating===<br />
Few reported issue when upgrading the contribs see [[Bugzilla:10286]] and [[Bugzilla:10097]]<br />
<br />
A full update can be done as follow :<br />
yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs<br />
<br />
It is important to do the usual<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
otherwise<br />
signal-event console-save<br />
<br />
failure to do this might leave the contribution not working and your certificates not renewed.<br />
<br />
===Configuration===<br />
There are several configuration database entries that need to be made in order to set up this contrib. Most of them tell the scripts which hostnames need to be part of your certificate.<br />
<br />
====Hosts and domains for the certificate====<br />
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:<br />
* Are configured on your SME Server (e.g., through the Server Manager), and<br />
* Are configured to use Let's Encrypt.<br />
<br />
For example, your SME Server may contain the following domains and hostnames:<br />
<br />
* domain1.com<br />
: www.domain1.com<br />
: mail.domain1.com<br />
: ftp.domain1.com<br />
* domain2.com<br />
: www.domain2.com<br />
: mail.domain2.com<br />
<br />
For each DOMAIN that you want to be included in the certificate, run this command:<br />
db domains setprop $DOMAIN letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db domains setprop domain1.com letsencryptSSLcert enabled<br />
<br />
For each HOSTNAME that you want to be included in the certificate, run this command:<br />
db hosts setprop $HOSTNAME letsencryptSSLcert enabled<br />
<br />
Using the above example, one invocation of the command would look like this:<br />
db hosts setprop www.domain1.com letsencryptSSLcert enabled<br />
<br />
You can also set this contrib to obtain a certificate for all domains, all hostnames, or all domains AND hostnames. <br />
config setprop letsencrypt configure all | domains | hosts<br />
<br />
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc. Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com. Setting this property to "all" will include all domain names and hostnames in the certificate. '''see note before setting this to "all"'''<br />
<br />
====Other configuration properties====<br />
No other settings are mandatory. However, it's recommended to configure an email address. If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this. Do so with this command:<br />
config setprop letsencrypt email admin@domain1.com<br />
<br />
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.<br />
<br />
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits. This should not be necessary in most cases, but if desired, use this command to do so:<br />
config setprop letsencrypt keysize NUMBER<br />
<br />
===Accept Let's Encrypt terms ===<br />
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]<br />
config setprop letsencrypt ACCEPT_TERMS yes<br />
<br />
===Enable Test Mode===<br />
The next step is to enable test mode. This will obtain certificates from the staging server. The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate. Enable test mode using this command:<br />
config setprop letsencrypt status test<br />
signal-event console-save<br />
<br />
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates. To do this, run<br />
dehydrated -c<br />
<br />
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].<br />
<br />
If this runs without errors, try to connect to your server-manager page. You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal. However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days. If this was successful, proceed to production.<br />
<br />
===Enable Production Mode===<br />
Once you've successfully tested your installation, set it to production mode using these commands:<br />
<br />
config setprop letsencrypt status enabled<br />
signal-event console-save<br />
<br />
Then obtain a new certificate from the Let's Encrypt production server:<br />
dehydrated -c -x<br />
<br />
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.<br />
<br />
If this command succeeded, congratulations! You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity. <br />
<br />
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.<br />
<br />
===Rush jobs===<br />
for the test ('''adjust the domains and hosts'''):<br />
config setprop letsencrypt ACCEPT_TERMS yes status test<br />
#foreach of your domains you want SSL do the following<br />
db domains setprop '''domain1.com''' letsencryptSSLcert enabled<br />
#foreach of your hosts (subdomains) you want SSL do the following<br />
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.<br />
<br />
for the production ('''adjust your email'''):<br />
config setprop letsencrypt status enabled email '''admin@domain1.com'''<br />
signal-event console-save<br />
dehydrated -c -x<br />
<br />
==Manual Installation of Dehydrated==<br />
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.<br />
<br />
===Contrib install of Dehydrated===<br />
The dehydrated script has been imported into the contribs repository and can be installed as follows:<br />
<br />
yum --enablerepo=smecontribs install dehydrated<br />
<br />
The script must be configured as described below.<br />
<br />
===Git install of latest version===<br />
<br />
If you need or want the absolute latest version of the script then you can manually install as follows:<br />
<br />
Begin by installing git:<br />
yum install git<br />
<br />
Then download the Dehydrated client:<br />
cd /etc<br />
git clone https://github.com/lukas2511/dehydrated<br />
mv dehydrated/dehydrated /usr/local/bin/<br />
<br />
===Manual Configuration of Dehydrated===<br />
<br />
You'll need to create two configuration files for Dehydrated.<br />
cd /etc/dehydrated<br />
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
nano -w domains.txt<br />
<br />
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:<br />
domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org<br />
Ctrl-X to exit, Y to save.<br />
<br />
Second, you'll need to create the configuration file '''config''':<br />
nano -w config<br />
<br />
It should look like this:<br />
#!/bin/bash<br />
# config<br />
# CA="https://acme-staging.api.letsencrypt.org/directory"<br />
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br />
HOOK="/usr/local/bin/dehydrated-hook"<br />
# E-mail to use during the registration (default: <unset>)<br />
CONTACT_EMAIL="admin@yourdomain.com"<br />
<br />
Ctrl-X to exit, Y to save.<br />
<br />
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA="). Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.<br />
<br />
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.<br />
nano /usr/local/bin/dehydrated-hook<br />
<br />
Its contents should look like this:<br />
#!/bin/bash<br />
<br />
if [ $1 = "deploy_cert" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
/sbin/e-smith/db configuration setprop modSSL key $KEY<br />
/sbin/e-smith/db configuration setprop modSSL crt $CERT<br />
/sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN<br />
/sbin/e-smith/signal-event ssl-update<br />
fi<br />
<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /usr/local/bin/dehydrated-hook<br />
<br />
You'll also need to create a custom template fragment for Apache:<br />
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf<br />
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME<br />
<br />
The contents of that file should look like:<br />
# Alias for letsencrypt<br />
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge<br />
Again, Ctrl-X to exit, Y to save.<br />
<br />
Expand the template and restart apache:<br />
expand-template /etc/httpd/conf/httpd.conf<br />
service httpd-e-smith restart<br />
<br />
Now you're ready to run dehydrated and get your certificate.<br />
dehydrated -c<br />
<br />
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run<br />
config show modSSL<br />
and make sure there are values set for crt, key, and CertificateChainFile.<br />
<br />
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run<br />
dehydrated -c -x<br />
<br />
to obtain trusted a trusted certificate.<br />
<br />
===Renewal===<br />
When run, the dehydrated script will check your existing certificate to see how long it's valid. If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates. If more than 30 days remain, the script will exit without further action. All that's necessary is to run dehydrated daily:<br />
nano -w /etc/cron.daily/call-dehydrated<br />
<br />
Enter the following in this file:<br />
#!/bin/bash<br />
/usr/bin/dehydrated -c<br />
Ctrl-X to exit, Y to save. Then make it executable:<br />
chmod +x /etc/cron.daily/call-dehydrated<br />
<br />
==Requiring SSL==<br />
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections. For any i-bays, you can do this using the server-manager page, or using a shell command. For the Primary i-bay, you'll need to use the shell command:<br />
db accounts setprop {accountname} SSL enabled<br />
or<br />
db accounts setprop Primary SSL enabled<br />
<br />
==Backup==<br />
Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding files and directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add<br />
Include=/etc/dehydrated<br />
<br />
to the Affa configuration file.<br />
<br />
== Troubleshooting ==<br />
===Certificate Errors===<br />
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:<br />
config setprop modSSL crt (old value)<br />
config setprop modSSL key (old value)<br />
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)<br />
<br />
If you did not have custom settings for modSSL, remove your changes with:<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
config delprop modSSL CertificateChainFile <br />
<br />
Once you've made these changes, do:<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
===Authorization Errors===<br />
The first thing is to check all your domains can resolve<br />
<br />
http://my.domain/.well-known/acme-challenge<br />
<br />
Check that the following files are correctly generated<br />
<br />
/etc/dehydrated/config<br />
/etc/dehydrated/domains.txt<br />
<br />
Set letsencrypt back to test and remove any generated keys<br />
<br />
db configuration setprop letsencrypt status test<br />
<br />
rm /etc/dehydrated/certs/* -rf<br />
rm /etc/dehydrated/accounts/* -rf<br />
<br />
Then run letsencrypt again<br />
<br />
dehydrated -c<br />
<br />
To restore the original certificates:<br />
<br />
config delprop modSSL CertificateChainFile<br />
config delprop modSSL crt<br />
config delprop modSSL key<br />
<br />
signal-event console-save<br />
<br />
===Errors===<br />
If you see the following:<br />
<br />
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/issues/2<br />
<br />
See above for removing private keys and regenerating<br />
<br />
<br />
If you see something like this you may have hit the rate limit:<br />
<br />
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}<br />
<br />
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md<br />
<br />
https://letsencrypt.org/docs/rate-limits/<br />
<br />
==Advanced Topics==<br />
===Obtaining certificates for other servers===<br />
The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib.<br />
<br />
You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do<br />
<br />
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt<br />
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname<br />
<br />
You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:<br />
<br />
hostname.domain.tld<br />
<br />
Then Ctrl-X to exit, Y to save.<br />
<br />
The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.<br />
<br />
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/<br />
nano -w 05deploy_cert_hostname<br />
<br />
As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10.<br />
<br />
At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then<br />
KEY=$3<br />
CERT=$4<br />
CHAIN=$6<br />
scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt<br />
scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key<br />
scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt<br />
ssh root@pbx "/sbin/service httpd reload"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
The following fragment would install the new certificate on a Proxmox VE host:<br />
<br />
{<br />
use strict;<br />
use warnings;<br />
use esmith::ConfigDB;<br />
<br />
my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");<br />
<br />
my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled';<br />
<br />
if ( $letsencryptStatus ne 'disabled' ) {<br />
<br />
$OUT .=<<'_EOF';<br />
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then<br />
KEY=$3<br />
CHAIN=$5<br />
scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key<br />
scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem<br />
ssh root@pve "systemctl restart pveproxy"<br />
echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld<br />
exit 0<br />
fi<br />
_EOF<br />
<br />
}<br />
}<br />
<br />
Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:<br />
signal-event console-save<br />
dehydrated -c<br />
<br />
These certificates will be automatically renewed, just like the main server certificate.<br />
<br />
===Obtaining certificates for a private SME Server===<br />
As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:<br />
* The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address<br />
* The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80<br />
* The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)<br />
<br />
This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:<br />
config setprop letsencrypt hookScript enabled<br />
config setprop letsencrypt host '''external.mydomain.tld'''<br />
config setprop letsencrypt user '''root'''<br />
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''<br />
signal-event console-save<br />
<br />
The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/<br />
<br />
= Bugs =<br />
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]<br />
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}<br />
<br />
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}<br />
<br />
= Changelog =<br />
Only released version in smecontrib are listed here.<br />
<br />
{{#smechangelog:smeserver-letsencrypt}}<br />
<br />
[[Category:Howto]] [[Category:Security]] [[Category:Howto]]<br />
[[Category: Administration:Certificates]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME9.0_Contribs_QA&diff=27718
SME9.0 Contribs QA
2015-05-04T13:55:34Z
<p>Mercyh: /* smeserver-smf */</p>
<hr />
<div>=Version 9 beta3 Contrib testing=<br />
This document lists Contribs that, need to be tested or have had been tested running under SME 9<br />
<br />
Contribs should work if they are perl or php based (unless php53 deprecated some functions needed) . Some binary applications will work as well.<br />
<br />
Contribs using perl modules might be broken due to change of path<br />
<br />
Please also see [[Contribs Bugreport]]<br />
<br />
==Test guidelines==<br />
Considerations_before_installing advises that Contribs for SME 9 have not yet been released, this is to avoid dev workload diagnosing bugs caused by contribs.<br />
<br />
Please don't post SME 9 bugs unless you can replicate the bug with the contrib removed or isolated.<br />
<br />
{{Note box|If you have suggestions, issues or solutions for a contrib, please post them in bugzilla {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}} }}<br />
<br />
==Setup==<br />
During the transition from SME8 to SME9, contrib packages will be migrated to the SME9 contrib repository. If the contrib is not yet in the SME8 Contrib repository and an entry in this Q&A suggests it will install properly then you will need to install the contrib from the SME8 repository.<br />
<br />
Check to see if you already have the sme8contribs repository set up using the command:<br />
db yum_repositories show sme8contribs<br />
If it returns nothing then you will need to create a repo named sme8contribs, which points to the SME 8 smecontribs repo<br />
<br />
<br />
db yum_repositories set sme8contribs repository \<br />
Name 'SME 8 - contribs' \<br />
MirrorList 'http://mirrorlist.contribs.org/mirrorlist/smecontribs-8' \<br />
GPGCheck yes \<br />
Visible no \<br />
status disabled<br />
<br />
signal-event yum-modify<br />
yum clean all<br />
<br />
<br />
{{Note box|'''now you will need to add the package from sme8contribs and smecontribs to resolve some problems of dependencies...'''}}<br />
<br />
{{Note box|'''you might also consider to add some external repo such as [[dag]] and [[epel]]...'''}}<br />
<br />
<br />
The following shows an example of how to install a contrib from the SME 8 repo:<br />
<br />
yum '''--enablerepo=sme8contribs,smecontribs''' install smeserver-openvpn-s2s<br />
<br />
Notice the additional phrase "sme8contribs," in the command line.<br />
<br />
Another example is as follows:<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
==Template for testing==<br />
<br />
=== not working===<br />
please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, and write in the wiki you tested it and it fails.<br /><br />
{{Tip box|the title of your bug should look to "'''sme9contribs:'''Can't locate esmith/FormMagick/Panel/passwordopt.pm" for example.}}<br />
BROKEN with your signature (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* bugs : [[bugzilla:NUMBER]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error :<br />
* workaround :<br />
* tested beyond installation : yes / no<br />
<br />
=== working===<br />
write here it works, with the following information :<br /><br />
<br />
WORKS with your signature. (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes / no<br />
<br />
Then please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, to ask to push the contribs to sme9contribs.<br /><br />
<br />
{{Tip box|The title of your bug should be for example "'''first import to sme9 tree [smeserver-mediawiki]'''"}}<br />
<br />
=Contribs=<br />
<br />
List of Contribs being tested<br />
* [http://bugs.contribs.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=SME+Contribs&format=table&action=wrap&version=9beta Bugs related to contribs in SME 9]<br />
<br />
<br />
<br />
==Need to test==<br />
<br />
===smeserver-adv-samba===<br />
*[[Advanced_Samba]]<br />
<br />
===smeserver-affa===<br />
*[[Affa]]<br />
<br />
===smeserver-ajaxterm===<br />
*[[Ajaxterm]]<br />
<br />
<br />
===smeserver-arpwatch===<br />
*[[arpwatch]]<br />
<br />
===smeserver-automysqlbackup===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:20, 15 January 2014 (MST)<br />
*wikipage : [[AutoMysqlBackup]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-automysqlbackup<br />
*version-release installed:<br />
automysqlbackup-3.0.RC6-3.el5.sme.noarch <br />
smeserver-automysqlbackup-3.0.RC6-3.el5.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8339]]<br />
<br />
===smeserver-awstats===<br />
*[[AWStats]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:06, 19 June 2014 (MDT) see [[bugzilla:8435]] and [[bugzilla:8450]]<br />
* wikipage : [[AWStats]]<br />
* to install : for now you have to install from epel, dag and smedev : yum --enablerepo=dag,epel,smedev install smeserver-awstats<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: awstats from dag, perl-Geo-IP from epel<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-BackupPC===<br />
<br />
*[[BackupPC]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:57, 21 April 2014 (MDT)<br />
* wikipage : [[BackupPC]]<br />
* to install :<br />
yum install smeserver-BackupPC --enablerepo=smecontribs,epel<br />
* version-release installed:<br />
smeserver-BackupPC-0.1-12.el5.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
see epel repository for backuppc<br />
BackupPC-3.3.0-2.el6.i686.rpm<br />
* tested beyond installation : yes<br />
it works as expected, it is my main network backup software. see [[bugzilla:8336]] for import to smecontribs<br />
<br />
===smeserver-bandwidthd===<br />
*[[bandwidthd]]<br />
<br />
===smeserver-bridge-interface===<br />
* [[BridgeInterface]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:19, 21 April 2014 (MDT)<br />
* wikipage : [[BridgeInterface]]<br />
* to install :<br />
yum --enablerepo=smecontribs,epel,dag install smeserver-bridge-interface<br />
* version-release installed:<br />
from sme9contribs<br />
smeserver-bridge-interface-0.2-1.el6.sme.noarch.rpm<br />
from base<br />
openssl098e-0.9.8e-17.el6.centos.2.i686.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
from epel,dag<br />
openvpn-2.3.1-3.el5.i386.rpm<br />
pkcs11-helper-1.07-2.el5.1.i386.rpm<br />
* tested beyond installation : yes<br />
<br />
It works as expected except that we must use some dependencies from dag and epel, see [[bugzilla:8337]]<br />
<br />
===smeserver-bugzilla===<br />
* no wiki<br />
<br />
===smeserver-cacti===<br />
*[[cacti]]<br />
<br />
===smeserver-crontab_manager===<br />
*[[Crontab_Manager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:33, 19 June 2014 (MDT) see [[bugzilla:8412]]<br />
* wikipage : [[Crontab_Manager]]<br />
* to install : yum install smeserver-crontab_manager --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dansguardian===<br />
*[[Dansguardian]]<br />
<br />
<br />
===smeserver-dar2===<br />
*[[DAR2]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*to install :<br />
enable [[stephdl]]<br />
yum install --enablerepo=stephdl smeserver-dar2<br />
*version-release installed:<br />
smeserver-dar2-0.0.3-1.el6.sme.noarch <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8508]]<br />
<br />
There is a bug raised against the setting 'smbfs' allowed by this contribs to backup on a remote host. The smbfs is obsolete now by cifs, you have to use cifs instead of smbfs. see [[bugzilla:8519]]<br />
<br />
===smeserver-ddclient===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 06:30, 21 June 2014 (MDT)<br />
*wikipage : [[ddclient]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-ddclient<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[epel]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8338]]<br />
<br />
===smeserver-denyhosts===<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:52, 29 March 2015 (CEST) see [[bugzilla:8428]]<br />
* wikipage : [[Denyhosts]]<br />
* to install : yum install smeserver-denyhosts --enablerepo=smedev,smecontribs,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dimp===<br />
* [[Dimp]]<br />
<br />
===smeserver-diskusage===<br />
*[[Diskusage]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:37, 19 June 2014 (MDT) see [[bugzilla:8410]]<br />
* wikipage : [[Diskusage]]<br />
* to install : yum install smeserver-diskusage --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-durep===<br />
*[[durep]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:22, 21 June 2014 (MDT) see [[bugzilla:8454]]<br />
* wikipage : [[durep]]<br />
* to install : yum install smeserver-durep --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-durep-1.5.0-1<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] and [[epel]] repositories<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-egroupware===<br />
*[[egroupware]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:28, 24 June 2014 (MDT) see [[bugzilla:8438]] see [[bugzilla:8487]]<br />
* wikipage : [[egroupware]]<br />
* to install : yum install smeserver-egroupware --enablerepo=smedev,Server_eGroupWare,epel<br />
* version-release installed: <br />
smeserver-egroupware-1.8.6-1.el6.sme.noarch<br /><br />
<br />
eGroupware-1.8.007.20140512-5.1.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs: [[Server_eGroupWare]] repository and epel and smedev for now but see [[bugzilla:8438]], the bug is pending the release in smecontribs (9.0)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-ejabberd===<br />
*[[Ejabberd]]<br />
<br />
===smeserver-ezmlm-web===<br />
*[[Ezmlm]]<br />
<br />
===smeserver-fetchmail===<br />
WORKS --[[User:Eastend99|Eastend99]] ([[User talk:Eastend99|talk]]) 14:36, 9 juni 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:47, 21 June 2014 (MDT) see [[bugzilla:8455]]<br />
*wikipage : [[Fetchmail]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-fetchmail<br />
*version-release installed:<br />
smeserver-fetchmail.noarch 0:1.6-1.el6.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, successfull retrieved e-mail<br />
<br />
===smeserver-freepbx===<br />
*[[FreePBX]]<br />
<br />
===smeserver-geoip===<br />
*[[GeoIP]]<br />
<br />
===smeserver-gollem===<br />
* no wiki, Horde plugin<br />
<br />
===smeserver-groupmembers-panel===<br />
*[[Groupmembers_Panel]]<br />
<br />
===smeserver-htbwshaper===<br />
*[[Wondershaper]] (need update)<br />
please see [[Qos]] this contrib is no longer maintained<br />
<br />
===smeserver-hwinfo===<br />
*[[Hardware Info]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*wikipage : [[Hardware Info]]<br />
*to install :<br />
enable [[stephdl]] and [[dag]]<br />
yum install --enablerepo=stephdl,dag smeserver-hwinfo<br />
*version-release installed:<br />
smeserver-hwinfo-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[dag]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8506]]<br />
<br />
===smeserver-hylafax===<br />
*[[HylaFax]]<br />
<br />
===smeserver-isoqlog===<br />
*[[isoqlog]]<br />
<br />
===smeserver-jeta===<br />
* no wiki<br />
<br />
===smeserver-kplaylist===<br />
*[[KPlaylist]]<br />
<br />
===smeserver-kronolith===<br />
*[[Kronolith]]<br />
<br />
===smeserver-lazy_admin_tools===<br />
*[[Lazy_Admin_Tools]]<br />
* works as is<br />
* to install <br />
yum --enablerepo=sme8contribs,smecontribs install smeserver-lazy_admin_tools<br />
--[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 04:04, 22 January 2015 (CET)<br />
<br />
===smeserver-madsonic===<br />
*[[Madsonic]]<br />
<br />
===smeserver-mailman===<br />
*[[Mailman]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:01, 20 June 2014 (MDT) see [[bugzilla:8453]]<br />
* wikipage : [[Mailman]]<br />
* to install : yum install smeserver-mailman --enablerepo=stephdl<br />
* version-release installed: mailman.x86_64 3:2.1.12-25.el6.sme smeserver-mailman.noarch 0:1.5.0-1.el6.sme<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] repository<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailsorting===<br />
*[[mailsorting]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:29, 23 June 2014 (MDT) see [[bugzilla:8465]]<br />
* wikipage : [[mailsorting]]<br />
* to install : yum install smeserver-mailsorting --enablerepo=stephdl,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: perl-Unicode-IMAPUtf7 (dag)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailstats===<br />
*[[mailstats]]<br />
Brian Read - 28Jan14 and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:35, 23 September 2014 (CEST) still in smedev but the bug is verified see [[bugzilla:8445]]<br />
* Installed ok.<br />
* tested beyond installation : only to the extent that it works with no data!! However it is pure perl, so I am not expecting it to fail<br />
Someone could build an RPM.<br />
tested beyond installation : Yes --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:56, 23 June 2014 (MDT)<br />
<br />
===smeserver-mimp===<br />
* [[Mimp]]<br />
<br />
===smeserver-mnemo===<br />
*[[Mnemo]]<br />
<br />
===smeserver-mod_dav===<br />
*[[DAV]]<br />
<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:35, 19 June 2014 (MDT) see [[bugzilla:8340]]<br />
* wikipage : [[DAV]]<br />
* to install : yum install smeserver-mod_dav --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mod_deflate===<br />
*[[mod_deflate]]<br />
<br />
===smeserver-mod_python===<br />
*[[Mod_Python]]<br />
<br />
===smeserver-nag===<br />
*[[Nag]]<br />
<br />
===smeserver-nagios===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-backup===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-nrpe===<br />
*[[Nagios_NRPE]]<br />
<br />
===smeserver-nagios-nsca===<br />
*[[Nagios_NSCA]]<br />
<br />
===smeserver-nagios-plugins-mysql===<br />
*[[Nagios]]<br />
<br />
===smeserver-nfs===<br />
*[[NFS]]<br />
<br />
===smeserver-oats===<br />
*[[Oats]]<br />
<br />
===smeserver-ocsinventory===<br />
*[[OCS_Inventory]]<br />
<br />
===smeserver-openoffice-portable===<br />
*[[OpenOffice_for_Windows]]<br />
<br />
===smeserver-openvpn-bridge===<br />
*[[OpenVPN_Bridge]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:11, 21 April 2014 (MDT)<br />
* wikipage : [[OpenVPN_Bridge]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-openvpn-bridge<br />
* version-release installed:<br />
perl-Net-OpenVPN-Manage-0.02-2.el6.sme.noarch.rpm<br />
perl-Net-Telnet-3.03-11.el6.noarch.rpm<br />
smeserver-openvpn-bridge-2.1-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes<br />
all rpms are available in sme9contribs<br />
<br />
===smeserver-openvpn-s2s===<br />
*[[OpenVPN_SiteToSite]]<br />
<br />
===smeserver-password===<br />
<br />
Work see [[bugzilla:8137]]<br />
<br />
* wikipage : [[Password]]<br />
* to install :<br />
yum install --enablerepo=smecontribs smeserver-password<br />
* version-release tried:<br />
smeserver-password-1.0.0-32.el5.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
all in smecontribs<br />
* error :<br />
* workaround : see [[bugzilla:8137]]<br />
* tested beyond installation : YES<br />
<br />
===smeserver-phpki=== <br />
*[[PHPki]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:25, 21 April 2014 (MDT)<br />
* wikipage : [[PHPki]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-phpki<br />
* version-release installed:<br />
php-process-5.3.3-27.el6_5.i686.rpm <br />
phpki-0.82-16.el6.sme.noarch.rpm<br />
smeserver-phpki-0.2-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
nothing at all<br />
* tested beyond installation : yes<br />
all rpms are in sme9contribs tree<br />
<br />
===smeserver-phpldapadmin===<br />
*[[Phpldapadmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:14, 21 June 2014 (MDT)-- see [[bugzilla:8456]]<br />
* wikipage : [[Phpldapadmin]]<br />
* to install : yum install smeserver-phpldapadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpmyadmin===<br />
*[[PHPMyAdmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:38, 19 June 2014 (MDT) see [[bugzilla:8413]]<br />
* wikipage : [[PHPMyAdmin]]<br />
* to install : yum install smeserver-phpmyadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpsysinfo===<br />
*[[Phpsysinfo]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:41, 21 June 2014 (MDT)<br />
*wikipage : [[Phpsysinfo]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-phpsysinfo<br />
*version-release installed: smeserver-phpsysinfo-3.1.13<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpvirtualbox===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[Phpvirtualbox]]<br />
*to install :<br />
yum install --enablerepo=stephdl,virtualbox smeserver-virtualbox smeserver-phpvirtualbox<br />
*version-release installed:<br />
smeserver-phpvirtualbox.noarch 0:4.3.0-10.el5.sme<br />
smeserver-virtualbox.noarch 0:4.3.0-5.el5.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: Virtualbox is in the virtualbox repository<br />
You have to install dkms but it is in the relevant epel repository<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpwebftp===<br />
*[[PhpWebFtp]]<br />
<br />
===smeserver-popfile===<br />
*[[popfile]]<br />
<br />
===smeserver-postgresql===<br />
*[[Postgres]] ?? should update this wiki page<br />
<br />
===smeserver-print-monitor===<br />
*[[LPRng print queue monitor]]<br />
<br />
*to install :<br />
yum install smeserver-print-monitor --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
*add template line<br />
nano /etc/e-smith/templates/etc/httpd/conf/httpd.conf/90e-smithAccess40LPRng<br />
add line : AuthBasicProvider external<br />
<br />
<Directory /var/www/html/LPRng><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<Directory /var/www/html/LPRng/admin><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<br />
*You should run this command<br />
signal-event console-save<br />
*or<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* tested Ecureuil<br />
<br />
===smeserver-qmHandle===<br />
*[[Qmhandle_mail_queue_manager]]<br />
WORKING --[[User:pmstewart|pmstewart]] ([[User talk:pmstewart|talk]]) 16:36, 7 October 2014 (MDT)<br />
<br />
Tested on Windows 8.1 all udpates installed in VirtualBox in production test server.<br />
<br />
*wiki-page: [[Qmhandle_mail_queue_manager]]<br />
*install: Add sme8contribs to yum as per testing critera<br />
*command: yum install smeserver-qmHandle --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version: smeserver-qmHandle.noarch 0:1.4-4.el5.sme<br />
*dependencies: no dependencies required<br />
*tested beyond install: yes - all server manager panel actions appear to work correctly<br />
<br />
===smeserver-qpsmtpd-spamassassinlevelstars===<br />
*[[Email#X-Spam-Level_Header_in_Email_Messages]]<br />
<br />
===smeserver-raidmonitor===<br />
*[[raidmonitor]]<br />
obsolete<br />
<br />
===smeserver-rdiff-backup===<br />
*[[rdiff-backup]]<br />
<br />
===smeserver-remoteuseraccess===<br />
*[[remoteuseraccess]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:17, 21 June 2014 (MDT)<br />
* wikipage : [[remoteuseraccess]]<br />
* to install : yum install smeserver-remoteuseraccess --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in smecontribs<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-rkhunter===<br />
*[[rkhunter]]<br />
<br />
===smeserver-roundcube===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[RoundCube]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-roundcube<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-sane===<br />
*[[SANE]]<br />
*WORKS<br />
*to install :<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version-release installed:<br />
smeserver-sane-0.1-7.el5.sme.noarch (sme8contribs)<br />
*dependencies<br />
sane-backends-1.0.21-3.el6.x86_64 (base)<br />
sane-backends-libs-1.0.21-3.el6.x86_64 (base)<br />
xinetd-2.3.14-39.el6_4.x86_64 (base)<br />
smeserver-xinetd-0.1-1.el5.sme.noarch (sme8contribs)<br />
*tested by Ecureuil<br />
<br />
===smeserver-sarg===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sarg]] & [[bugzilla:8174]]<br />
* to install : yum install smeserver-sarg --enablerepo=stephdl<br />
* version-release installed: smeserver-sarg-2.3.1-1 sarg-2.3.1<br />
* dependencies not in smeos,smeaddons,smecontribs: sarg-2.3.1 smeserver-sarg-2.3.1-1<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] repository<br />
<br />
===smeserver-shared-folders===<br />
*[[SharedFolders]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 10:35, 27 March 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:41, 21 June 2014 (MDT)<br />
* wikipage : [[SharedFolders]], see also [http://forums.contribs.org/index.php/topic,50325.msg253425.html#msg253425 this] forum post<br />
* to install : <br />
yum --enablerepo=smecontribs install smeserver-shared-folders<br />
* version-release installed: <br />
smeserver-shared-folders noarch 0.3-2.el6.sme smecontribs<br />
* dependencies not in smeos,smeaddons,smecontribs: <br />
smeserver-mod_dav noarch 1.0-1.el5.sme smecontribs <br />
* tested beyond installation : shared folder creation works, local and public access not tested<br />
<br />
===smeserver-sitemaker===<br />
*[[SME_Site_Maker]]<br />
<br />
===smeserver-sme8admin===<br />
*[[Sme8admin]]<br />
obsoletes; see sme9admin<br />
<br />
===smeserver-sme9admin===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sme9admin]]<br />
* to install : yum install smeserver-sme9admin --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-sme9admin-1.5-12<br />
* dependencies not in smeos,smeaddons,smecontribs: hddtemp<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] and [[epel]] repositories<br />
<br />
===smeserver-smf===<br />
WORKS --[[User:Mercyh|Mercyh]] 29 April 2015 see [[bugzilla:8919]]<br />
* wikipage: [[SMF]]<br />
* to install: This install is more complex as the rpm was never moved to SME8contribs repo this means you will need to setup the SME7contribs repo [[SME8.0_Contribs_QA#Setup]]<br />
you would then install with : yum --enablerepo=sme7contribs install smeserver--smf<br />
* dependencies: no dependencies needed<br />
* tested beyond installation: yes in production on SME9 64bit server<br />
'''* This installs a VERY OLD version of SMF with known security issues. You MUST update the install to the latest version of SMF before running it in production.'''<br />
<br />
===smeserver-subsonic===<br />
*[[Subsonic]]<br />
<br />
===smeserver-subversion===<br />
*[[subversion]]<br />
<br />
===smeserver-sysmon===<br />
*[[sysmon]]<br />
<br />
===smeserver-tftp-server===<br />
*[[Tftp_server]]<br />
<br />
===smeserver-theaddressbook===<br />
*[[The Address Book]]<br />
<br />
===smeserver-thinclient===<br />
*[[Thinclient]]<br />
Warning: The contrib allows to specify the TFTP server as "Self". This worked well under SME7 but not under SME8. To get this working under SME8, we had to choose the SME server's IP address to achieve the same result as "self" otherwise the clients cannot find/load from the TFTP server. We have reported this as bug 6542 for the contrib but with this workaround, the contrib is working well under SME8. <br />
Bug has been reported as work for me, so please comment on it if you can replicate.<br />
<br />
===smeserver-transmission===<br />
Works see [[bugzilla:8134]]<br />
<br />
* wikipage : [[transmission]]<br />
* to install :<br />
yum install --enablerepo=stephdl smeserver-transmission<br />
* version-release tried: smeserver-transmission-0.0.2-1.el6.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs: in stephdl<br />
transmission-2.76-1geekery.x86_64.rpm<br />
transmission-cli-2.76-1geekery.x86_64.rpm<br />
transmission-common-2.76-1geekery.x86_64.rpm<br />
transmission-daemon-2.76-1geekery.x86_64.rpm <br />
libevent2-2.0.10-1geekery.x86_64.rpm<br />
<br />
* tested beyond installation : Go :)<br />
<br />
===smeserver-tw-logonscript===<br />
*[[Smeserver-tw-logonscript]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 12:05, 26 June 2014 (CET) * wikipage : [[Smeserver-tw-logonscript]], <br />
<br />
BROKEN<br />
installs correctly, server manager panel is not working.<br />
<br />
<br />
* bugs : [[bugzilla:8471]]<br />
* to install : <br />
yum --enablerepo=sme8contribs install smeserver-tw-logonscript<br />
* version-release installed: <br />
smeserver-tw-logonscript noarch 1.3-21.el5.sme sme8contribs 44 k<br />
<br />
* tested beyond installation :<br />
Internal Server Error<br />
The server encountered an internal error or misconfiguration and was unable to complete your request.<br />
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.<br />
More information about this error may be available in the server error log.<br />
<br />
Unable to locate the source of the error from /var/log logfiles.<br />
<br />
===smeserver-unjunkmgr===<br />
*[[Sme-unjunkmgr]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:07, 25 April 2014 (MDT)<br />
* bugs : [[bugzilla:8353]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
# rpm -qa smeserver-unjunkmgr<br />
smeserver-unjunkmgr-2.1-3.el5.sme.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : see bug report<br />
* tested beyond installation : broken<br />
<br />
===smeserver-updates===<br />
*[[Smeserver-updates]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:17, 23 June 2014 (MDT) see [[bugzilla:8463]]<br />
* wikipage : [[Smeserver-updates]]<br />
* to install : yum install Smeserver-updates --enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-usbdisksmanager===<br />
*[[Disk_Manager]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:56, 12 October 2014 (CEST)<br />
* wikipage : [[Disk_Manager]]<br />
* bugs : [[bugzilla:8597]]<br />
* to install : http://mirror.de-labrusse.fr/Sme-Server/smeserver-usbdisksmanager/<br />
* version-release tried: smeserver-usbdisksmanager-1.0-3.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : not for the moment<br />
* tested beyond installation : no<br />
<br />
===smeserver-userpanel===<br />
*[[UserManager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:14, 23 June 2014 (MDT) see [[bugzilla:8464]]<br />
* wikipage : [[UserManager]]<br />
* to install : yum install smeserver-userpanel enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-userpanels===<br />
*[http://www.dungog.net/wiki/Usermanager#Change_password Smeserver-userpanels] , needs wiki page at contribs<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:55, 29 March 2015 (CEST)<br />
* wikipage : TO DO<br />
* to install : yum install smeserver-userpanels enablerepo=smecontribs,stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-UserWebSpace===<br />
* no wiki page<br />
<br />
===smeserver-vacation===<br />
*[[Vacation]]<br />
<br />
===smeserver-virtualbox===<br />
see [[SME9.0_Contribs_QA#smeserver-phpvirtualbox]]<br />
<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-wbl===<br />
* bug: [[bugzilla:8521]]<br />
* Installation fails as some Template2Expand fragment directives clash with those from qpsmtpd.<br />
*[[Email#Email_WBL_server_manager_panel]]<br />
<br />
===smeserver-webconsole===<br />
*[[webconsole]]<br />
<br />
===smeserver-webshare===<br />
*[[Webshare]] <br />
<br />
===smeserver-wordpress===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:38, 15 January 2014 (MST)<br />
*wikipage : [[wordpress]] see [[bugzilla:8451]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-wordpress<br />
*version-release installed:<br />
smeserver-wordpress-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in epel<br />
php-IDNA_Convert-0.8.0-1.el6.noarch 1/8 <br />
php-simplepie-1.3.1-3.el6.noarch 2/8 <br />
php-process-5.3.3-27.el6_5.x86_64 3/8 <br />
1:enchant-1.5.0-4.el6.x86_64 4/8 <br />
php-enchant-5.3.3-27.el6_5.x86_64 5/8 <br />
php-PHPMailer-5.2.2-1.el6.noarch 6/8 <br />
wordpress-3.8-1.el6.noarch <br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-xinetd===<br />
*[[xinetd]]<br />
===smeserver-zarafa-unix===<br />
*[[Zarafa_on_SME_9]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:46, 19 June 2014 (MDT) see [[bugzilla:7383]]<br />
* wikipage : [[Zarafa_on_SME_9]]<br />
* to install : please see How to install directly in the [[Zarafa_on_SME_9|wikipage]] <br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: All Zarafa RPM's must be downloaded, extracted and installed using "yum localinstall". See Wiki page for detailed instructions.<br />
* tested beyond installation : Yes<br />
<br />
== Won't be ported to SME9 ==<br />
===smeserver-vmware-server===<br />
vmware server is not supported anymore please consider using virtualbox, or KVM...</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME9.0_Contribs_QA&diff=27717
SME9.0 Contribs QA
2015-04-29T15:07:39Z
<p>Mercyh: /* Need to test */</p>
<hr />
<div>=Version 9 beta3 Contrib testing=<br />
This document lists Contribs that, need to be tested or have had been tested running under SME 9<br />
<br />
Contribs should work if they are perl or php based (unless php53 deprecated some functions needed) . Some binary applications will work as well.<br />
<br />
Contribs using perl modules might be broken due to change of path<br />
<br />
Please also see [[Contribs Bugreport]]<br />
<br />
==Test guidelines==<br />
Considerations_before_installing advises that Contribs for SME 9 have not yet been released, this is to avoid dev workload diagnosing bugs caused by contribs.<br />
<br />
Please don't post SME 9 bugs unless you can replicate the bug with the contrib removed or isolated.<br />
<br />
{{Note box|If you have suggestions, issues or solutions for a contrib, please post them in bugzilla {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}} }}<br />
<br />
==Setup==<br />
During the transition from SME8 to SME9, contrib packages will be migrated to the SME9 contrib repository. If the contrib is not yet in the SME8 Contrib repository and an entry in this Q&A suggests it will install properly then you will need to install the contrib from the SME8 repository.<br />
<br />
Check to see if you already have the sme8contribs repository set up using the command:<br />
db yum_repositories show sme8contribs<br />
If it returns nothing then you will need to create a repo named sme8contribs, which points to the SME 8 smecontribs repo<br />
<br />
<br />
db yum_repositories set sme8contribs repository \<br />
Name 'SME 8 - contribs' \<br />
MirrorList 'http://mirrorlist.contribs.org/mirrorlist/smecontribs-8' \<br />
GPGCheck yes \<br />
Visible no \<br />
status disabled<br />
<br />
signal-event yum-modify<br />
yum clean all<br />
<br />
<br />
{{Note box|'''now you will need to add the package from sme8contribs and smecontribs to resolve some problems of dependencies...'''}}<br />
<br />
{{Note box|'''you might also consider to add some external repo such as [[dag]] and [[epel]]...'''}}<br />
<br />
<br />
The following shows an example of how to install a contrib from the SME 8 repo:<br />
<br />
yum '''--enablerepo=sme8contribs,smecontribs''' install smeserver-openvpn-s2s<br />
<br />
Notice the additional phrase "sme8contribs," in the command line.<br />
<br />
Another example is as follows:<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
==Template for testing==<br />
<br />
=== not working===<br />
please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, and write in the wiki you tested it and it fails.<br /><br />
{{Tip box|the title of your bug should look to "'''sme9contribs:'''Can't locate esmith/FormMagick/Panel/passwordopt.pm" for example.}}<br />
BROKEN with your signature (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* bugs : [[bugzilla:NUMBER]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error :<br />
* workaround :<br />
* tested beyond installation : yes / no<br />
<br />
=== working===<br />
write here it works, with the following information :<br /><br />
<br />
WORKS with your signature. (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes / no<br />
<br />
Then please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, to ask to push the contribs to sme9contribs.<br /><br />
<br />
{{Tip box|The title of your bug should be for example "'''first import to sme9 tree [smeserver-mediawiki]'''"}}<br />
<br />
=Contribs=<br />
<br />
List of Contribs being tested<br />
* [http://bugs.contribs.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=SME+Contribs&format=table&action=wrap&version=9beta Bugs related to contribs in SME 9]<br />
<br />
<br />
<br />
==Need to test==<br />
<br />
===smeserver-adv-samba===<br />
*[[Advanced_Samba]]<br />
<br />
===smeserver-affa===<br />
*[[Affa]]<br />
<br />
===smeserver-ajaxterm===<br />
*[[Ajaxterm]]<br />
<br />
<br />
===smeserver-arpwatch===<br />
*[[arpwatch]]<br />
<br />
===smeserver-automysqlbackup===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:20, 15 January 2014 (MST)<br />
*wikipage : [[AutoMysqlBackup]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-automysqlbackup<br />
*version-release installed:<br />
automysqlbackup-3.0.RC6-3.el5.sme.noarch <br />
smeserver-automysqlbackup-3.0.RC6-3.el5.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8339]]<br />
<br />
===smeserver-awstats===<br />
*[[AWStats]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:06, 19 June 2014 (MDT) see [[bugzilla:8435]] and [[bugzilla:8450]]<br />
* wikipage : [[AWStats]]<br />
* to install : for now you have to install from epel, dag and smedev : yum --enablerepo=dag,epel,smedev install smeserver-awstats<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: awstats from dag, perl-Geo-IP from epel<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-BackupPC===<br />
<br />
*[[BackupPC]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:57, 21 April 2014 (MDT)<br />
* wikipage : [[BackupPC]]<br />
* to install :<br />
yum install smeserver-BackupPC --enablerepo=smecontribs,epel<br />
* version-release installed:<br />
smeserver-BackupPC-0.1-12.el5.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
see epel repository for backuppc<br />
BackupPC-3.3.0-2.el6.i686.rpm<br />
* tested beyond installation : yes<br />
it works as expected, it is my main network backup software. see [[bugzilla:8336]] for import to smecontribs<br />
<br />
===smeserver-bandwidthd===<br />
*[[bandwidthd]]<br />
<br />
===smeserver-bridge-interface===<br />
* [[BridgeInterface]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:19, 21 April 2014 (MDT)<br />
* wikipage : [[BridgeInterface]]<br />
* to install :<br />
yum --enablerepo=smecontribs,epel,dag install smeserver-bridge-interface<br />
* version-release installed:<br />
from sme9contribs<br />
smeserver-bridge-interface-0.2-1.el6.sme.noarch.rpm<br />
from base<br />
openssl098e-0.9.8e-17.el6.centos.2.i686.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
from epel,dag<br />
openvpn-2.3.1-3.el5.i386.rpm<br />
pkcs11-helper-1.07-2.el5.1.i386.rpm<br />
* tested beyond installation : yes<br />
<br />
It works as expected except that we must use some dependencies from dag and epel, see [[bugzilla:8337]]<br />
<br />
===smeserver-bugzilla===<br />
* no wiki<br />
<br />
===smeserver-cacti===<br />
*[[cacti]]<br />
<br />
===smeserver-crontab_manager===<br />
*[[Crontab_Manager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:33, 19 June 2014 (MDT) see [[bugzilla:8412]]<br />
* wikipage : [[Crontab_Manager]]<br />
* to install : yum install smeserver-crontab_manager --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dansguardian===<br />
*[[Dansguardian]]<br />
<br />
<br />
===smeserver-dar2===<br />
*[[DAR2]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*to install :<br />
enable [[stephdl]]<br />
yum install --enablerepo=stephdl smeserver-dar2<br />
*version-release installed:<br />
smeserver-dar2-0.0.3-1.el6.sme.noarch <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8508]]<br />
<br />
There is a bug raised against the setting 'smbfs' allowed by this contribs to backup on a remote host. The smbfs is obsolete now by cifs, you have to use cifs instead of smbfs. see [[bugzilla:8519]]<br />
<br />
===smeserver-ddclient===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 06:30, 21 June 2014 (MDT)<br />
*wikipage : [[ddclient]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-ddclient<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[epel]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8338]]<br />
<br />
===smeserver-denyhosts===<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:52, 29 March 2015 (CEST) see [[bugzilla:8428]]<br />
* wikipage : [[Denyhosts]]<br />
* to install : yum install smeserver-denyhosts --enablerepo=smedev,smecontribs,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dimp===<br />
* [[Dimp]]<br />
<br />
===smeserver-diskusage===<br />
*[[Diskusage]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:37, 19 June 2014 (MDT) see [[bugzilla:8410]]<br />
* wikipage : [[Diskusage]]<br />
* to install : yum install smeserver-diskusage --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-durep===<br />
*[[durep]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:22, 21 June 2014 (MDT) see [[bugzilla:8454]]<br />
* wikipage : [[durep]]<br />
* to install : yum install smeserver-durep --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-durep-1.5.0-1<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] and [[epel]] repositories<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-egroupware===<br />
*[[egroupware]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:28, 24 June 2014 (MDT) see [[bugzilla:8438]] see [[bugzilla:8487]]<br />
* wikipage : [[egroupware]]<br />
* to install : yum install smeserver-egroupware --enablerepo=smedev,Server_eGroupWare,epel<br />
* version-release installed: <br />
smeserver-egroupware-1.8.6-1.el6.sme.noarch<br /><br />
<br />
eGroupware-1.8.007.20140512-5.1.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs: [[Server_eGroupWare]] repository and epel and smedev for now but see [[bugzilla:8438]], the bug is pending the release in smecontribs (9.0)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-ejabberd===<br />
*[[Ejabberd]]<br />
<br />
===smeserver-ezmlm-web===<br />
*[[Ezmlm]]<br />
<br />
===smeserver-fetchmail===<br />
WORKS --[[User:Eastend99|Eastend99]] ([[User talk:Eastend99|talk]]) 14:36, 9 juni 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:47, 21 June 2014 (MDT) see [[bugzilla:8455]]<br />
*wikipage : [[Fetchmail]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-fetchmail<br />
*version-release installed:<br />
smeserver-fetchmail.noarch 0:1.6-1.el6.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, successfull retrieved e-mail<br />
<br />
===smeserver-freepbx===<br />
*[[FreePBX]]<br />
<br />
===smeserver-geoip===<br />
*[[GeoIP]]<br />
<br />
===smeserver-gollem===<br />
* no wiki, Horde plugin<br />
<br />
===smeserver-groupmembers-panel===<br />
*[[Groupmembers_Panel]]<br />
<br />
===smeserver-htbwshaper===<br />
*[[Wondershaper]] (need update)<br />
please see [[Qos]] this contrib is no longer maintained<br />
<br />
===smeserver-hwinfo===<br />
*[[Hardware Info]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*wikipage : [[Hardware Info]]<br />
*to install :<br />
enable [[stephdl]] and [[dag]]<br />
yum install --enablerepo=stephdl,dag smeserver-hwinfo<br />
*version-release installed:<br />
smeserver-hwinfo-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[dag]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8506]]<br />
<br />
===smeserver-hylafax===<br />
*[[HylaFax]]<br />
<br />
===smeserver-isoqlog===<br />
*[[isoqlog]]<br />
<br />
===smeserver-jeta===<br />
* no wiki<br />
<br />
===smeserver-kplaylist===<br />
*[[KPlaylist]]<br />
<br />
===smeserver-kronolith===<br />
*[[Kronolith]]<br />
<br />
===smeserver-lazy_admin_tools===<br />
*[[Lazy_Admin_Tools]]<br />
* works as is<br />
* to install <br />
yum --enablerepo=sme8contribs,smecontribs install smeserver-lazy_admin_tools<br />
--[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 04:04, 22 January 2015 (CET)<br />
<br />
===smeserver-madsonic===<br />
*[[Madsonic]]<br />
<br />
===smeserver-mailman===<br />
*[[Mailman]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:01, 20 June 2014 (MDT) see [[bugzilla:8453]]<br />
* wikipage : [[Mailman]]<br />
* to install : yum install smeserver-mailman --enablerepo=stephdl<br />
* version-release installed: mailman.x86_64 3:2.1.12-25.el6.sme smeserver-mailman.noarch 0:1.5.0-1.el6.sme<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] repository<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailsorting===<br />
*[[mailsorting]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:29, 23 June 2014 (MDT) see [[bugzilla:8465]]<br />
* wikipage : [[mailsorting]]<br />
* to install : yum install smeserver-mailsorting --enablerepo=stephdl,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: perl-Unicode-IMAPUtf7 (dag)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailstats===<br />
*[[mailstats]]<br />
Brian Read - 28Jan14 and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:35, 23 September 2014 (CEST) still in smedev but the bug is verified see [[bugzilla:8445]]<br />
* Installed ok.<br />
* tested beyond installation : only to the extent that it works with no data!! However it is pure perl, so I am not expecting it to fail<br />
Someone could build an RPM.<br />
tested beyond installation : Yes --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:56, 23 June 2014 (MDT)<br />
<br />
===smeserver-mimp===<br />
* [[Mimp]]<br />
<br />
===smeserver-mnemo===<br />
*[[Mnemo]]<br />
<br />
===smeserver-mod_dav===<br />
*[[DAV]]<br />
<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:35, 19 June 2014 (MDT) see [[bugzilla:8340]]<br />
* wikipage : [[DAV]]<br />
* to install : yum install smeserver-mod_dav --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mod_deflate===<br />
*[[mod_deflate]]<br />
<br />
===smeserver-mod_python===<br />
*[[Mod_Python]]<br />
<br />
===smeserver-nag===<br />
*[[Nag]]<br />
<br />
===smeserver-nagios===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-backup===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-nrpe===<br />
*[[Nagios_NRPE]]<br />
<br />
===smeserver-nagios-nsca===<br />
*[[Nagios_NSCA]]<br />
<br />
===smeserver-nagios-plugins-mysql===<br />
*[[Nagios]]<br />
<br />
===smeserver-nfs===<br />
*[[NFS]]<br />
<br />
===smeserver-oats===<br />
*[[Oats]]<br />
<br />
===smeserver-ocsinventory===<br />
*[[OCS_Inventory]]<br />
<br />
===smeserver-openoffice-portable===<br />
*[[OpenOffice_for_Windows]]<br />
<br />
===smeserver-openvpn-bridge===<br />
*[[OpenVPN_Bridge]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:11, 21 April 2014 (MDT)<br />
* wikipage : [[OpenVPN_Bridge]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-openvpn-bridge<br />
* version-release installed:<br />
perl-Net-OpenVPN-Manage-0.02-2.el6.sme.noarch.rpm<br />
perl-Net-Telnet-3.03-11.el6.noarch.rpm<br />
smeserver-openvpn-bridge-2.1-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes<br />
all rpms are available in sme9contribs<br />
<br />
===smeserver-openvpn-s2s===<br />
*[[OpenVPN_SiteToSite]]<br />
<br />
===smeserver-password===<br />
<br />
Work see [[bugzilla:8137]]<br />
<br />
* wikipage : [[Password]]<br />
* to install :<br />
yum install --enablerepo=smecontribs smeserver-password<br />
* version-release tried:<br />
smeserver-password-1.0.0-32.el5.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
all in smecontribs<br />
* error :<br />
* workaround : see [[bugzilla:8137]]<br />
* tested beyond installation : YES<br />
<br />
===smeserver-phpki=== <br />
*[[PHPki]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:25, 21 April 2014 (MDT)<br />
* wikipage : [[PHPki]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-phpki<br />
* version-release installed:<br />
php-process-5.3.3-27.el6_5.i686.rpm <br />
phpki-0.82-16.el6.sme.noarch.rpm<br />
smeserver-phpki-0.2-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
nothing at all<br />
* tested beyond installation : yes<br />
all rpms are in sme9contribs tree<br />
<br />
===smeserver-phpldapadmin===<br />
*[[Phpldapadmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:14, 21 June 2014 (MDT)-- see [[bugzilla:8456]]<br />
* wikipage : [[Phpldapadmin]]<br />
* to install : yum install smeserver-phpldapadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpmyadmin===<br />
*[[PHPMyAdmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:38, 19 June 2014 (MDT) see [[bugzilla:8413]]<br />
* wikipage : [[PHPMyAdmin]]<br />
* to install : yum install smeserver-phpmyadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpsysinfo===<br />
*[[Phpsysinfo]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:41, 21 June 2014 (MDT)<br />
*wikipage : [[Phpsysinfo]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-phpsysinfo<br />
*version-release installed: smeserver-phpsysinfo-3.1.13<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpvirtualbox===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[Phpvirtualbox]]<br />
*to install :<br />
yum install --enablerepo=stephdl,virtualbox smeserver-virtualbox smeserver-phpvirtualbox<br />
*version-release installed:<br />
smeserver-phpvirtualbox.noarch 0:4.3.0-10.el5.sme<br />
smeserver-virtualbox.noarch 0:4.3.0-5.el5.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: Virtualbox is in the virtualbox repository<br />
You have to install dkms but it is in the relevant epel repository<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpwebftp===<br />
*[[PhpWebFtp]]<br />
<br />
===smeserver-popfile===<br />
*[[popfile]]<br />
<br />
===smeserver-postgresql===<br />
*[[Postgres]] ?? should update this wiki page<br />
<br />
===smeserver-print-monitor===<br />
*[[LPRng print queue monitor]]<br />
<br />
*to install :<br />
yum install smeserver-print-monitor --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
*add template line<br />
nano /etc/e-smith/templates/etc/httpd/conf/httpd.conf/90e-smithAccess40LPRng<br />
add line : AuthBasicProvider external<br />
<br />
<Directory /var/www/html/LPRng><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<Directory /var/www/html/LPRng/admin><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<br />
*You should run this command<br />
signal-event console-save<br />
*or<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* tested Ecureuil<br />
<br />
===smeserver-qmHandle===<br />
*[[Qmhandle_mail_queue_manager]]<br />
WORKING --[[User:pmstewart|pmstewart]] ([[User talk:pmstewart|talk]]) 16:36, 7 October 2014 (MDT)<br />
<br />
Tested on Windows 8.1 all udpates installed in VirtualBox in production test server.<br />
<br />
*wiki-page: [[Qmhandle_mail_queue_manager]]<br />
*install: Add sme8contribs to yum as per testing critera<br />
*command: yum install smeserver-qmHandle --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version: smeserver-qmHandle.noarch 0:1.4-4.el5.sme<br />
*dependencies: no dependencies required<br />
*tested beyond install: yes - all server manager panel actions appear to work correctly<br />
<br />
===smeserver-qpsmtpd-spamassassinlevelstars===<br />
*[[Email#X-Spam-Level_Header_in_Email_Messages]]<br />
<br />
===smeserver-raidmonitor===<br />
*[[raidmonitor]]<br />
obsolete<br />
<br />
===smeserver-rdiff-backup===<br />
*[[rdiff-backup]]<br />
<br />
===smeserver-remoteuseraccess===<br />
*[[remoteuseraccess]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:17, 21 June 2014 (MDT)<br />
* wikipage : [[remoteuseraccess]]<br />
* to install : yum install smeserver-remoteuseraccess --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in smecontribs<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-rkhunter===<br />
*[[rkhunter]]<br />
<br />
===smeserver-roundcube===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[RoundCube]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-roundcube<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-sane===<br />
*[[SANE]]<br />
*WORKS<br />
*to install :<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version-release installed:<br />
smeserver-sane-0.1-7.el5.sme.noarch (sme8contribs)<br />
*dependencies<br />
sane-backends-1.0.21-3.el6.x86_64 (base)<br />
sane-backends-libs-1.0.21-3.el6.x86_64 (base)<br />
xinetd-2.3.14-39.el6_4.x86_64 (base)<br />
smeserver-xinetd-0.1-1.el5.sme.noarch (sme8contribs)<br />
*tested by Ecureuil<br />
<br />
===smeserver-sarg===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sarg]] & [[bugzilla:8174]]<br />
* to install : yum install smeserver-sarg --enablerepo=stephdl<br />
* version-release installed: smeserver-sarg-2.3.1-1 sarg-2.3.1<br />
* dependencies not in smeos,smeaddons,smecontribs: sarg-2.3.1 smeserver-sarg-2.3.1-1<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] repository<br />
<br />
===smeserver-shared-folders===<br />
*[[SharedFolders]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 10:35, 27 March 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:41, 21 June 2014 (MDT)<br />
* wikipage : [[SharedFolders]], see also [http://forums.contribs.org/index.php/topic,50325.msg253425.html#msg253425 this] forum post<br />
* to install : <br />
yum --enablerepo=smecontribs install smeserver-shared-folders<br />
* version-release installed: <br />
smeserver-shared-folders noarch 0.3-2.el6.sme smecontribs<br />
* dependencies not in smeos,smeaddons,smecontribs: <br />
smeserver-mod_dav noarch 1.0-1.el5.sme smecontribs <br />
* tested beyond installation : shared folder creation works, local and public access not tested<br />
<br />
===smeserver-sitemaker===<br />
*[[SME_Site_Maker]]<br />
<br />
===smeserver-sme8admin===<br />
*[[Sme8admin]]<br />
obsoletes; see sme9admin<br />
<br />
===smeserver-sme9admin===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sme9admin]]<br />
* to install : yum install smeserver-sme9admin --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-sme9admin-1.5-12<br />
* dependencies not in smeos,smeaddons,smecontribs: hddtemp<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] and [[epel]] repositories<br />
<br />
===smeserver-smf===<br />
WORKS --[[User:Mercyh|Mercyh]] 29 April 2015 see [[bugzilla:8919]]<br />
* wikipage: [[SMF]]<br />
* to install: This install is more complex as the rpm was never moved to SME8contribs repo this means you will need to setup the SME7contribs repo [[SME8.0_Contribs_QA#Setup]]<br />
you would then install with : yum --enablerepo=sme7contribs install smeserver--smf<br />
* dependencies: no dependencies needed<br />
* tested beyond installation: yes in production on SME9 64bit server<br />
<br />
===smeserver-subsonic===<br />
*[[Subsonic]]<br />
<br />
===smeserver-subversion===<br />
*[[subversion]]<br />
<br />
===smeserver-sysmon===<br />
*[[sysmon]]<br />
<br />
===smeserver-tftp-server===<br />
*[[Tftp_server]]<br />
<br />
===smeserver-theaddressbook===<br />
*[[The Address Book]]<br />
<br />
===smeserver-thinclient===<br />
*[[Thinclient]]<br />
Warning: The contrib allows to specify the TFTP server as "Self". This worked well under SME7 but not under SME8. To get this working under SME8, we had to choose the SME server's IP address to achieve the same result as "self" otherwise the clients cannot find/load from the TFTP server. We have reported this as bug 6542 for the contrib but with this workaround, the contrib is working well under SME8. <br />
Bug has been reported as work for me, so please comment on it if you can replicate.<br />
<br />
===smeserver-transmission===<br />
Works see [[bugzilla:8134]]<br />
<br />
* wikipage : [[transmission]]<br />
* to install :<br />
yum install --enablerepo=stephdl smeserver-transmission<br />
* version-release tried: smeserver-transmission-0.0.2-1.el6.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs: in stephdl<br />
transmission-2.76-1geekery.x86_64.rpm<br />
transmission-cli-2.76-1geekery.x86_64.rpm<br />
transmission-common-2.76-1geekery.x86_64.rpm<br />
transmission-daemon-2.76-1geekery.x86_64.rpm <br />
libevent2-2.0.10-1geekery.x86_64.rpm<br />
<br />
* tested beyond installation : Go :)<br />
<br />
===smeserver-tw-logonscript===<br />
*[[Smeserver-tw-logonscript]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 12:05, 26 June 2014 (CET) * wikipage : [[Smeserver-tw-logonscript]], <br />
<br />
BROKEN<br />
installs correctly, server manager panel is not working.<br />
<br />
<br />
* bugs : [[bugzilla:8471]]<br />
* to install : <br />
yum --enablerepo=sme8contribs install smeserver-tw-logonscript<br />
* version-release installed: <br />
smeserver-tw-logonscript noarch 1.3-21.el5.sme sme8contribs 44 k<br />
<br />
* tested beyond installation :<br />
Internal Server Error<br />
The server encountered an internal error or misconfiguration and was unable to complete your request.<br />
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.<br />
More information about this error may be available in the server error log.<br />
<br />
Unable to locate the source of the error from /var/log logfiles.<br />
<br />
===smeserver-unjunkmgr===<br />
*[[Sme-unjunkmgr]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:07, 25 April 2014 (MDT)<br />
* bugs : [[bugzilla:8353]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
# rpm -qa smeserver-unjunkmgr<br />
smeserver-unjunkmgr-2.1-3.el5.sme.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : see bug report<br />
* tested beyond installation : broken<br />
<br />
===smeserver-updates===<br />
*[[Smeserver-updates]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:17, 23 June 2014 (MDT) see [[bugzilla:8463]]<br />
* wikipage : [[Smeserver-updates]]<br />
* to install : yum install Smeserver-updates --enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-usbdisksmanager===<br />
*[[Disk_Manager]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:56, 12 October 2014 (CEST)<br />
* wikipage : [[Disk_Manager]]<br />
* bugs : [[bugzilla:8597]]<br />
* to install : http://mirror.de-labrusse.fr/Sme-Server/smeserver-usbdisksmanager/<br />
* version-release tried: smeserver-usbdisksmanager-1.0-3.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : not for the moment<br />
* tested beyond installation : no<br />
<br />
===smeserver-userpanel===<br />
*[[UserManager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:14, 23 June 2014 (MDT) see [[bugzilla:8464]]<br />
* wikipage : [[UserManager]]<br />
* to install : yum install smeserver-userpanel enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-userpanels===<br />
*[http://www.dungog.net/wiki/Usermanager#Change_password Smeserver-userpanels] , needs wiki page at contribs<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:55, 29 March 2015 (CEST)<br />
* wikipage : TO DO<br />
* to install : yum install smeserver-userpanels enablerepo=smecontribs,stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-UserWebSpace===<br />
* no wiki page<br />
<br />
===smeserver-vacation===<br />
*[[Vacation]]<br />
<br />
===smeserver-virtualbox===<br />
see [[SME9.0_Contribs_QA#smeserver-phpvirtualbox]]<br />
<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-wbl===<br />
* bug: [[bugzilla:8521]]<br />
* Installation fails as some Template2Expand fragment directives clash with those from qpsmtpd.<br />
*[[Email#Email_WBL_server_manager_panel]]<br />
<br />
===smeserver-webconsole===<br />
*[[webconsole]]<br />
<br />
===smeserver-webshare===<br />
*[[Webshare]] <br />
<br />
===smeserver-wordpress===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:38, 15 January 2014 (MST)<br />
*wikipage : [[wordpress]] see [[bugzilla:8451]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-wordpress<br />
*version-release installed:<br />
smeserver-wordpress-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in epel<br />
php-IDNA_Convert-0.8.0-1.el6.noarch 1/8 <br />
php-simplepie-1.3.1-3.el6.noarch 2/8 <br />
php-process-5.3.3-27.el6_5.x86_64 3/8 <br />
1:enchant-1.5.0-4.el6.x86_64 4/8 <br />
php-enchant-5.3.3-27.el6_5.x86_64 5/8 <br />
php-PHPMailer-5.2.2-1.el6.noarch 6/8 <br />
wordpress-3.8-1.el6.noarch <br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-xinetd===<br />
*[[xinetd]]<br />
===smeserver-zarafa-unix===<br />
*[[Zarafa_on_SME_9]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:46, 19 June 2014 (MDT) see [[bugzilla:7383]]<br />
* wikipage : [[Zarafa_on_SME_9]]<br />
* to install : please see How to install directly in the [[Zarafa_on_SME_9|wikipage]] <br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: All Zarafa RPM's must be downloaded, extracted and installed using "yum localinstall". See Wiki page for detailed instructions.<br />
* tested beyond installation : Yes<br />
<br />
== Won't be ported to SME9 ==<br />
===smeserver-vmware-server===<br />
vmware server is not supported anymore please consider using virtualbox, or KVM...</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME9.0_Contribs_QA&diff=27716
SME9.0 Contribs QA
2015-04-29T14:50:31Z
<p>Mercyh: /* smeserver-smf */</p>
<hr />
<div>=Version 9 beta3 Contrib testing=<br />
This document lists Contribs that, need to be tested or have had been tested running under SME 9<br />
<br />
Contribs should work if they are perl or php based (unless php53 deprecated some functions needed) . Some binary applications will work as well.<br />
<br />
Contribs using perl modules might be broken due to change of path<br />
<br />
Please also see [[Contribs Bugreport]]<br />
<br />
==Test guidelines==<br />
Considerations_before_installing advises that Contribs for SME 9 have not yet been released, this is to avoid dev workload diagnosing bugs caused by contribs.<br />
<br />
Please don't post SME 9 bugs unless you can replicate the bug with the contrib removed or isolated.<br />
<br />
{{Note box|If you have suggestions, issues or solutions for a contrib, please post them in bugzilla {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}} }}<br />
<br />
==Setup==<br />
During the transition from SME8 to SME9, contrib packages will be migrated to the SME9 contrib repository. If the contrib is not yet in the SME8 Contrib repository and an entry in this Q&A suggests it will install properly then you will need to install the contrib from the SME8 repository.<br />
<br />
Check to see if you already have the sme8contribs repository set up using the command:<br />
db yum_repositories show sme8contribs<br />
If it returns nothing then you will need to create a repo named sme8contribs, which points to the SME 8 smecontribs repo<br />
<br />
<br />
db yum_repositories set sme8contribs repository \<br />
Name 'SME 8 - contribs' \<br />
MirrorList 'http://mirrorlist.contribs.org/mirrorlist/smecontribs-8' \<br />
GPGCheck yes \<br />
Visible no \<br />
status disabled<br />
<br />
signal-event yum-modify<br />
yum clean all<br />
<br />
<br />
{{Note box|'''now you will need to add the package from sme8contribs and smecontribs to resolve some problems of dependencies...'''}}<br />
<br />
{{Note box|'''you might also consider to add some external repo such as [[dag]] and [[epel]]...'''}}<br />
<br />
<br />
The following shows an example of how to install a contrib from the SME 8 repo:<br />
<br />
yum '''--enablerepo=sme8contribs,smecontribs''' install smeserver-openvpn-s2s<br />
<br />
Notice the additional phrase "sme8contribs," in the command line.<br />
<br />
Another example is as follows:<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
==Template for testing==<br />
<br />
=== not working===<br />
please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, and write in the wiki you tested it and it fails.<br /><br />
{{Tip box|the title of your bug should look to "'''sme9contribs:'''Can't locate esmith/FormMagick/Panel/passwordopt.pm" for example.}}<br />
BROKEN with your signature (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* bugs : [[bugzilla:NUMBER]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error :<br />
* workaround :<br />
* tested beyond installation : yes / no<br />
<br />
=== working===<br />
write here it works, with the following information :<br /><br />
<br />
WORKS with your signature. (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes / no<br />
<br />
Then please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, to ask to push the contribs to sme9contribs.<br /><br />
<br />
{{Tip box|The title of your bug should be for example "'''first import to sme9 tree [smeserver-mediawiki]'''"}}<br />
<br />
=Contribs=<br />
<br />
List of Contribs being tested<br />
* [http://bugs.contribs.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=SME+Contribs&format=table&action=wrap&version=9beta Bugs related to contribs in SME 9]<br />
<br />
<br />
<br />
==Need to test==<br />
<br />
===smeserver-adv-samba===<br />
*[[Advanced_Samba]]<br />
<br />
===smeserver-affa===<br />
*[[Affa]]<br />
<br />
===smeserver-ajaxterm===<br />
*[[Ajaxterm]]<br />
<br />
<br />
===smeserver-arpwatch===<br />
*[[arpwatch]]<br />
<br />
===smeserver-automysqlbackup===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:20, 15 January 2014 (MST)<br />
*wikipage : [[AutoMysqlBackup]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-automysqlbackup<br />
*version-release installed:<br />
automysqlbackup-3.0.RC6-3.el5.sme.noarch <br />
smeserver-automysqlbackup-3.0.RC6-3.el5.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8339]]<br />
<br />
===smeserver-awstats===<br />
*[[AWStats]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:06, 19 June 2014 (MDT) see [[bugzilla:8435]] and [[bugzilla:8450]]<br />
* wikipage : [[AWStats]]<br />
* to install : for now you have to install from epel, dag and smedev : yum --enablerepo=dag,epel,smedev install smeserver-awstats<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: awstats from dag, perl-Geo-IP from epel<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-BackupPC===<br />
<br />
*[[BackupPC]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:57, 21 April 2014 (MDT)<br />
* wikipage : [[BackupPC]]<br />
* to install :<br />
yum install smeserver-BackupPC --enablerepo=smecontribs,epel<br />
* version-release installed:<br />
smeserver-BackupPC-0.1-12.el5.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
see epel repository for backuppc<br />
BackupPC-3.3.0-2.el6.i686.rpm<br />
* tested beyond installation : yes<br />
it works as expected, it is my main network backup software. see [[bugzilla:8336]] for import to smecontribs<br />
<br />
===smeserver-bandwidthd===<br />
*[[bandwidthd]]<br />
<br />
===smeserver-bridge-interface===<br />
* [[BridgeInterface]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:19, 21 April 2014 (MDT)<br />
* wikipage : [[BridgeInterface]]<br />
* to install :<br />
yum --enablerepo=smecontribs,epel,dag install smeserver-bridge-interface<br />
* version-release installed:<br />
from sme9contribs<br />
smeserver-bridge-interface-0.2-1.el6.sme.noarch.rpm<br />
from base<br />
openssl098e-0.9.8e-17.el6.centos.2.i686.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
from epel,dag<br />
openvpn-2.3.1-3.el5.i386.rpm<br />
pkcs11-helper-1.07-2.el5.1.i386.rpm<br />
* tested beyond installation : yes<br />
<br />
It works as expected except that we must use some dependencies from dag and epel, see [[bugzilla:8337]]<br />
<br />
===smeserver-bugzilla===<br />
* no wiki<br />
<br />
===smeserver-cacti===<br />
*[[cacti]]<br />
<br />
===smeserver-crontab_manager===<br />
*[[Crontab_Manager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:33, 19 June 2014 (MDT) see [[bugzilla:8412]]<br />
* wikipage : [[Crontab_Manager]]<br />
* to install : yum install smeserver-crontab_manager --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dansguardian===<br />
*[[Dansguardian]]<br />
<br />
<br />
===smeserver-dar2===<br />
*[[DAR2]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*to install :<br />
enable [[stephdl]]<br />
yum install --enablerepo=stephdl smeserver-dar2<br />
*version-release installed:<br />
smeserver-dar2-0.0.3-1.el6.sme.noarch <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8508]]<br />
<br />
There is a bug raised against the setting 'smbfs' allowed by this contribs to backup on a remote host. The smbfs is obsolete now by cifs, you have to use cifs instead of smbfs. see [[bugzilla:8519]]<br />
<br />
===smeserver-ddclient===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 06:30, 21 June 2014 (MDT)<br />
*wikipage : [[ddclient]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-ddclient<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[epel]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8338]]<br />
<br />
===smeserver-denyhosts===<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:52, 29 March 2015 (CEST) see [[bugzilla:8428]]<br />
* wikipage : [[Denyhosts]]<br />
* to install : yum install smeserver-denyhosts --enablerepo=smedev,smecontribs,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dimp===<br />
* [[Dimp]]<br />
<br />
===smeserver-diskusage===<br />
*[[Diskusage]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:37, 19 June 2014 (MDT) see [[bugzilla:8410]]<br />
* wikipage : [[Diskusage]]<br />
* to install : yum install smeserver-diskusage --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-durep===<br />
*[[durep]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:22, 21 June 2014 (MDT) see [[bugzilla:8454]]<br />
* wikipage : [[durep]]<br />
* to install : yum install smeserver-durep --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-durep-1.5.0-1<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] and [[epel]] repositories<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-egroupware===<br />
*[[egroupware]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:28, 24 June 2014 (MDT) see [[bugzilla:8438]] see [[bugzilla:8487]]<br />
* wikipage : [[egroupware]]<br />
* to install : yum install smeserver-egroupware --enablerepo=smedev,Server_eGroupWare,epel<br />
* version-release installed: <br />
smeserver-egroupware-1.8.6-1.el6.sme.noarch<br /><br />
<br />
eGroupware-1.8.007.20140512-5.1.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs: [[Server_eGroupWare]] repository and epel and smedev for now but see [[bugzilla:8438]], the bug is pending the release in smecontribs (9.0)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-ejabberd===<br />
*[[Ejabberd]]<br />
<br />
===smeserver-ezmlm-web===<br />
*[[Ezmlm]]<br />
<br />
===smeserver-fetchmail===<br />
WORKS --[[User:Eastend99|Eastend99]] ([[User talk:Eastend99|talk]]) 14:36, 9 juni 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:47, 21 June 2014 (MDT) see [[bugzilla:8455]]<br />
*wikipage : [[Fetchmail]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-fetchmail<br />
*version-release installed:<br />
smeserver-fetchmail.noarch 0:1.6-1.el6.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, successfull retrieved e-mail<br />
<br />
===smeserver-freepbx===<br />
*[[FreePBX]]<br />
<br />
===smeserver-geoip===<br />
*[[GeoIP]]<br />
<br />
===smeserver-gollem===<br />
* no wiki, Horde plugin<br />
<br />
===smeserver-groupmembers-panel===<br />
*[[Groupmembers_Panel]]<br />
<br />
===smeserver-htbwshaper===<br />
*[[Wondershaper]] (need update)<br />
please see [[Qos]] this contrib is no longer maintained<br />
<br />
===smeserver-hwinfo===<br />
*[[Hardware Info]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*wikipage : [[Hardware Info]]<br />
*to install :<br />
enable [[stephdl]] and [[dag]]<br />
yum install --enablerepo=stephdl,dag smeserver-hwinfo<br />
*version-release installed:<br />
smeserver-hwinfo-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[dag]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8506]]<br />
<br />
===smeserver-hylafax===<br />
*[[HylaFax]]<br />
<br />
===smeserver-isoqlog===<br />
*[[isoqlog]]<br />
<br />
===smeserver-jeta===<br />
* no wiki<br />
<br />
===smeserver-kplaylist===<br />
*[[KPlaylist]]<br />
<br />
===smeserver-kronolith===<br />
*[[Kronolith]]<br />
<br />
===smeserver-lazy_admin_tools===<br />
*[[Lazy_Admin_Tools]]<br />
* works as is<br />
* to install <br />
yum --enablerepo=sme8contribs,smecontribs install smeserver-lazy_admin_tools<br />
--[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 04:04, 22 January 2015 (CET)<br />
<br />
===smeserver-madsonic===<br />
*[[Madsonic]]<br />
<br />
===smeserver-mailman===<br />
*[[Mailman]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:01, 20 June 2014 (MDT) see [[bugzilla:8453]]<br />
* wikipage : [[Mailman]]<br />
* to install : yum install smeserver-mailman --enablerepo=stephdl<br />
* version-release installed: mailman.x86_64 3:2.1.12-25.el6.sme smeserver-mailman.noarch 0:1.5.0-1.el6.sme<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] repository<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailsorting===<br />
*[[mailsorting]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:29, 23 June 2014 (MDT) see [[bugzilla:8465]]<br />
* wikipage : [[mailsorting]]<br />
* to install : yum install smeserver-mailsorting --enablerepo=stephdl,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: perl-Unicode-IMAPUtf7 (dag)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailstats===<br />
*[[mailstats]]<br />
Brian Read - 28Jan14 and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:35, 23 September 2014 (CEST) still in smedev but the bug is verified see [[bugzilla:8445]]<br />
* Installed ok.<br />
* tested beyond installation : only to the extent that it works with no data!! However it is pure perl, so I am not expecting it to fail<br />
Someone could build an RPM.<br />
tested beyond installation : Yes --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:56, 23 June 2014 (MDT)<br />
<br />
===smeserver-mimp===<br />
* [[Mimp]]<br />
<br />
===smeserver-mnemo===<br />
*[[Mnemo]]<br />
<br />
===smeserver-mod_dav===<br />
*[[DAV]]<br />
<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:35, 19 June 2014 (MDT) see [[bugzilla:8340]]<br />
* wikipage : [[DAV]]<br />
* to install : yum install smeserver-mod_dav --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mod_deflate===<br />
*[[mod_deflate]]<br />
<br />
===smeserver-mod_python===<br />
*[[Mod_Python]]<br />
<br />
===smeserver-nag===<br />
*[[Nag]]<br />
<br />
===smeserver-nagios===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-backup===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-nrpe===<br />
*[[Nagios_NRPE]]<br />
<br />
===smeserver-nagios-nsca===<br />
*[[Nagios_NSCA]]<br />
<br />
===smeserver-nagios-plugins-mysql===<br />
*[[Nagios]]<br />
<br />
===smeserver-nfs===<br />
*[[NFS]]<br />
<br />
===smeserver-oats===<br />
*[[Oats]]<br />
<br />
===smeserver-ocsinventory===<br />
*[[OCS_Inventory]]<br />
<br />
===smeserver-openoffice-portable===<br />
*[[OpenOffice_for_Windows]]<br />
<br />
===smeserver-openvpn-bridge===<br />
*[[OpenVPN_Bridge]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:11, 21 April 2014 (MDT)<br />
* wikipage : [[OpenVPN_Bridge]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-openvpn-bridge<br />
* version-release installed:<br />
perl-Net-OpenVPN-Manage-0.02-2.el6.sme.noarch.rpm<br />
perl-Net-Telnet-3.03-11.el6.noarch.rpm<br />
smeserver-openvpn-bridge-2.1-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes<br />
all rpms are available in sme9contribs<br />
<br />
===smeserver-openvpn-s2s===<br />
*[[OpenVPN_SiteToSite]]<br />
<br />
===smeserver-password===<br />
<br />
Work see [[bugzilla:8137]]<br />
<br />
* wikipage : [[Password]]<br />
* to install :<br />
yum install --enablerepo=smecontribs smeserver-password<br />
* version-release tried:<br />
smeserver-password-1.0.0-32.el5.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
all in smecontribs<br />
* error :<br />
* workaround : see [[bugzilla:8137]]<br />
* tested beyond installation : YES<br />
<br />
===smeserver-phpki=== <br />
*[[PHPki]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:25, 21 April 2014 (MDT)<br />
* wikipage : [[PHPki]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-phpki<br />
* version-release installed:<br />
php-process-5.3.3-27.el6_5.i686.rpm <br />
phpki-0.82-16.el6.sme.noarch.rpm<br />
smeserver-phpki-0.2-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
nothing at all<br />
* tested beyond installation : yes<br />
all rpms are in sme9contribs tree<br />
<br />
===smeserver-phpldapadmin===<br />
*[[Phpldapadmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:14, 21 June 2014 (MDT)-- see [[bugzilla:8456]]<br />
* wikipage : [[Phpldapadmin]]<br />
* to install : yum install smeserver-phpldapadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpmyadmin===<br />
*[[PHPMyAdmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:38, 19 June 2014 (MDT) see [[bugzilla:8413]]<br />
* wikipage : [[PHPMyAdmin]]<br />
* to install : yum install smeserver-phpmyadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpsysinfo===<br />
*[[Phpsysinfo]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:41, 21 June 2014 (MDT)<br />
*wikipage : [[Phpsysinfo]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-phpsysinfo<br />
*version-release installed: smeserver-phpsysinfo-3.1.13<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpvirtualbox===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[Phpvirtualbox]]<br />
*to install :<br />
yum install --enablerepo=stephdl,virtualbox smeserver-virtualbox smeserver-phpvirtualbox<br />
*version-release installed:<br />
smeserver-phpvirtualbox.noarch 0:4.3.0-10.el5.sme<br />
smeserver-virtualbox.noarch 0:4.3.0-5.el5.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: Virtualbox is in the virtualbox repository<br />
You have to install dkms but it is in the relevant epel repository<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpwebftp===<br />
*[[PhpWebFtp]]<br />
<br />
===smeserver-popfile===<br />
*[[popfile]]<br />
<br />
===smeserver-postgresql===<br />
*[[Postgres]] ?? should update this wiki page<br />
<br />
===smeserver-print-monitor===<br />
*[[LPRng print queue monitor]]<br />
<br />
*to install :<br />
yum install smeserver-print-monitor --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
*add template line<br />
nano /etc/e-smith/templates/etc/httpd/conf/httpd.conf/90e-smithAccess40LPRng<br />
add line : AuthBasicProvider external<br />
<br />
<Directory /var/www/html/LPRng><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<Directory /var/www/html/LPRng/admin><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<br />
*You should run this command<br />
signal-event console-save<br />
*or<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* tested Ecureuil<br />
<br />
===smeserver-qmHandle===<br />
*[[Qmhandle_mail_queue_manager]]<br />
WORKING --[[User:pmstewart|pmstewart]] ([[User talk:pmstewart|talk]]) 16:36, 7 October 2014 (MDT)<br />
<br />
Tested on Windows 8.1 all udpates installed in VirtualBox in production test server.<br />
<br />
*wiki-page: [[Qmhandle_mail_queue_manager]]<br />
*install: Add sme8contribs to yum as per testing critera<br />
*command: yum install smeserver-qmHandle --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version: smeserver-qmHandle.noarch 0:1.4-4.el5.sme<br />
*dependencies: no dependencies required<br />
*tested beyond install: yes - all server manager panel actions appear to work correctly<br />
<br />
===smeserver-qpsmtpd-spamassassinlevelstars===<br />
*[[Email#X-Spam-Level_Header_in_Email_Messages]]<br />
<br />
===smeserver-raidmonitor===<br />
*[[raidmonitor]]<br />
obsolete<br />
<br />
===smeserver-rdiff-backup===<br />
*[[rdiff-backup]]<br />
<br />
===smeserver-remoteuseraccess===<br />
*[[remoteuseraccess]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:17, 21 June 2014 (MDT)<br />
* wikipage : [[remoteuseraccess]]<br />
* to install : yum install smeserver-remoteuseraccess --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in smecontribs<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-rkhunter===<br />
*[[rkhunter]]<br />
<br />
===smeserver-roundcube===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[RoundCube]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-roundcube<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-sane===<br />
*[[SANE]]<br />
*WORKS<br />
*to install :<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version-release installed:<br />
smeserver-sane-0.1-7.el5.sme.noarch (sme8contribs)<br />
*dependencies<br />
sane-backends-1.0.21-3.el6.x86_64 (base)<br />
sane-backends-libs-1.0.21-3.el6.x86_64 (base)<br />
xinetd-2.3.14-39.el6_4.x86_64 (base)<br />
smeserver-xinetd-0.1-1.el5.sme.noarch (sme8contribs)<br />
*tested by Ecureuil<br />
<br />
===smeserver-sarg===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sarg]] & [[bugzilla:8174]]<br />
* to install : yum install smeserver-sarg --enablerepo=stephdl<br />
* version-release installed: smeserver-sarg-2.3.1-1 sarg-2.3.1<br />
* dependencies not in smeos,smeaddons,smecontribs: sarg-2.3.1 smeserver-sarg-2.3.1-1<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] repository<br />
<br />
===smeserver-shared-folders===<br />
*[[SharedFolders]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 10:35, 27 March 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:41, 21 June 2014 (MDT)<br />
* wikipage : [[SharedFolders]], see also [http://forums.contribs.org/index.php/topic,50325.msg253425.html#msg253425 this] forum post<br />
* to install : <br />
yum --enablerepo=smecontribs install smeserver-shared-folders<br />
* version-release installed: <br />
smeserver-shared-folders noarch 0.3-2.el6.sme smecontribs<br />
* dependencies not in smeos,smeaddons,smecontribs: <br />
smeserver-mod_dav noarch 1.0-1.el5.sme smecontribs <br />
* tested beyond installation : shared folder creation works, local and public access not tested<br />
<br />
===smeserver-sitemaker===<br />
*[[SME_Site_Maker]]<br />
<br />
===smeserver-sme8admin===<br />
*[[Sme8admin]]<br />
obsoletes; see sme9admin<br />
<br />
===smeserver-sme9admin===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sme9admin]]<br />
* to install : yum install smeserver-sme9admin --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-sme9admin-1.5-12<br />
* dependencies not in smeos,smeaddons,smecontribs: hddtemp<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] and [[epel]] repositories<br />
<br />
===smeserver-smf===<br />
WORKS --[[User:Mercyh|Mercyh]] 29 April 2015<br />
* wikipage: [[SMF]]<br />
* to install: This install is more complex as the rpm was never moved to SME8contribs repo this means you will need to setup the SME7contribs repo [[SME8.0_Contribs_QA#Setup]]<br />
you would then install with : yum --enablerepo=sme7contribs install smeserver--smf<br />
* dependencies: no dependencies needed<br />
* tested beyond installation: yes in production on SME9 64bit server<br />
<br />
===smeserver-subsonic===<br />
*[[Subsonic]]<br />
<br />
===smeserver-subversion===<br />
*[[subversion]]<br />
<br />
===smeserver-sysmon===<br />
*[[sysmon]]<br />
<br />
===smeserver-tftp-server===<br />
*[[Tftp_server]]<br />
<br />
===smeserver-theaddressbook===<br />
*[[The Address Book]]<br />
<br />
===smeserver-thinclient===<br />
*[[Thinclient]]<br />
Warning: The contrib allows to specify the TFTP server as "Self". This worked well under SME7 but not under SME8. To get this working under SME8, we had to choose the SME server's IP address to achieve the same result as "self" otherwise the clients cannot find/load from the TFTP server. We have reported this as bug 6542 for the contrib but with this workaround, the contrib is working well under SME8. <br />
Bug has been reported as work for me, so please comment on it if you can replicate.<br />
<br />
===smeserver-transmission===<br />
Works see [[bugzilla:8134]]<br />
<br />
* wikipage : [[transmission]]<br />
* to install :<br />
yum install --enablerepo=stephdl smeserver-transmission<br />
* version-release tried: smeserver-transmission-0.0.2-1.el6.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs: in stephdl<br />
transmission-2.76-1geekery.x86_64.rpm<br />
transmission-cli-2.76-1geekery.x86_64.rpm<br />
transmission-common-2.76-1geekery.x86_64.rpm<br />
transmission-daemon-2.76-1geekery.x86_64.rpm <br />
libevent2-2.0.10-1geekery.x86_64.rpm<br />
<br />
* tested beyond installation : Go :)<br />
<br />
===smeserver-tw-logonscript===<br />
*[[Smeserver-tw-logonscript]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 12:05, 26 June 2014 (CET) * wikipage : [[Smeserver-tw-logonscript]], <br />
<br />
BROKEN<br />
installs correctly, server manager panel is not working.<br />
<br />
<br />
* bugs : [[bugzilla:8471]]<br />
* to install : <br />
yum --enablerepo=sme8contribs install smeserver-tw-logonscript<br />
* version-release installed: <br />
smeserver-tw-logonscript noarch 1.3-21.el5.sme sme8contribs 44 k<br />
<br />
* tested beyond installation :<br />
Internal Server Error<br />
The server encountered an internal error or misconfiguration and was unable to complete your request.<br />
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.<br />
More information about this error may be available in the server error log.<br />
<br />
Unable to locate the source of the error from /var/log logfiles.<br />
<br />
===smeserver-unjunkmgr===<br />
*[[Sme-unjunkmgr]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:07, 25 April 2014 (MDT)<br />
* bugs : [[bugzilla:8353]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
# rpm -qa smeserver-unjunkmgr<br />
smeserver-unjunkmgr-2.1-3.el5.sme.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : see bug report<br />
* tested beyond installation : broken<br />
<br />
===smeserver-updates===<br />
*[[Smeserver-updates]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:17, 23 June 2014 (MDT) see [[bugzilla:8463]]<br />
* wikipage : [[Smeserver-updates]]<br />
* to install : yum install Smeserver-updates --enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-usbdisksmanager===<br />
*[[Disk_Manager]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:56, 12 October 2014 (CEST)<br />
* wikipage : [[Disk_Manager]]<br />
* bugs : [[bugzilla:8597]]<br />
* to install : http://mirror.de-labrusse.fr/Sme-Server/smeserver-usbdisksmanager/<br />
* version-release tried: smeserver-usbdisksmanager-1.0-3.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : not for the moment<br />
* tested beyond installation : no<br />
<br />
===smeserver-userpanel===<br />
*[[UserManager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:14, 23 June 2014 (MDT) see [[bugzilla:8464]]<br />
* wikipage : [[UserManager]]<br />
* to install : yum install smeserver-userpanel enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-userpanels===<br />
*[http://www.dungog.net/wiki/Usermanager#Change_password Smeserver-userpanels] , needs wiki page at contribs<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:55, 29 March 2015 (CEST)<br />
* wikipage : TO DO<br />
* to install : yum install smeserver-userpanels enablerepo=smecontribs,stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-UserWebSpace===<br />
* no wiki page<br />
<br />
===smeserver-vacation===<br />
*[[Vacation]]<br />
<br />
===smeserver-virtualbox===<br />
see [[SME9.0_Contribs_QA#smeserver-phpvirtualbox]]<br />
<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-wbl===<br />
* bug: [[bugzilla:8521]]<br />
* Installation fails as some Template2Expand fragment directives clash with those from qpsmtpd.<br />
*[[Email#Email_WBL_server_manager_panel]]<br />
<br />
===smeserver-webconsole===<br />
*[[webconsole]]<br />
<br />
===smeserver-webshare===<br />
*[[Webshare]] <br />
<br />
===smeserver-wordpress===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:38, 15 January 2014 (MST)<br />
*wikipage : [[wordpress]] see [[bugzilla:8451]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-wordpress<br />
*version-release installed:<br />
smeserver-wordpress-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in epel<br />
php-IDNA_Convert-0.8.0-1.el6.noarch 1/8 <br />
php-simplepie-1.3.1-3.el6.noarch 2/8 <br />
php-process-5.3.3-27.el6_5.x86_64 3/8 <br />
1:enchant-1.5.0-4.el6.x86_64 4/8 <br />
php-enchant-5.3.3-27.el6_5.x86_64 5/8 <br />
php-PHPMailer-5.2.2-1.el6.noarch 6/8 <br />
wordpress-3.8-1.el6.noarch <br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-xinetd===<br />
*[[xinetd]]<br />
===smeserver-zarafa-unix===<br />
*[[Zarafa_on_SME_9]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:46, 19 June 2014 (MDT) see [[bugzilla:7383]]<br />
* wikipage : [[Zarafa_on_SME_9]]<br />
* to install : please see How to install directly in the [[Zarafa_on_SME_9|wikipage]] <br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: All Zarafa RPM's must be downloaded, extracted and installed using "yum localinstall". See Wiki page for detailed instructions.<br />
* tested beyond installation : Yes<br />
<br />
== Won't be ported to SME9 ==<br />
===smeserver-vmware-server===<br />
vmware server is not supported anymore please consider using virtualbox, or KVM...</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME9.0_Contribs_QA&diff=27715
SME9.0 Contribs QA
2015-04-29T14:47:12Z
<p>Mercyh: /* Need to test */</p>
<hr />
<div>=Version 9 beta3 Contrib testing=<br />
This document lists Contribs that, need to be tested or have had been tested running under SME 9<br />
<br />
Contribs should work if they are perl or php based (unless php53 deprecated some functions needed) . Some binary applications will work as well.<br />
<br />
Contribs using perl modules might be broken due to change of path<br />
<br />
Please also see [[Contribs Bugreport]]<br />
<br />
==Test guidelines==<br />
Considerations_before_installing advises that Contribs for SME 9 have not yet been released, this is to avoid dev workload diagnosing bugs caused by contribs.<br />
<br />
Please don't post SME 9 bugs unless you can replicate the bug with the contrib removed or isolated.<br />
<br />
{{Note box|If you have suggestions, issues or solutions for a contrib, please post them in bugzilla {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}} }}<br />
<br />
==Setup==<br />
During the transition from SME8 to SME9, contrib packages will be migrated to the SME9 contrib repository. If the contrib is not yet in the SME8 Contrib repository and an entry in this Q&A suggests it will install properly then you will need to install the contrib from the SME8 repository.<br />
<br />
Check to see if you already have the sme8contribs repository set up using the command:<br />
db yum_repositories show sme8contribs<br />
If it returns nothing then you will need to create a repo named sme8contribs, which points to the SME 8 smecontribs repo<br />
<br />
<br />
db yum_repositories set sme8contribs repository \<br />
Name 'SME 8 - contribs' \<br />
MirrorList 'http://mirrorlist.contribs.org/mirrorlist/smecontribs-8' \<br />
GPGCheck yes \<br />
Visible no \<br />
status disabled<br />
<br />
signal-event yum-modify<br />
yum clean all<br />
<br />
<br />
{{Note box|'''now you will need to add the package from sme8contribs and smecontribs to resolve some problems of dependencies...'''}}<br />
<br />
{{Note box|'''you might also consider to add some external repo such as [[dag]] and [[epel]]...'''}}<br />
<br />
<br />
The following shows an example of how to install a contrib from the SME 8 repo:<br />
<br />
yum '''--enablerepo=sme8contribs,smecontribs''' install smeserver-openvpn-s2s<br />
<br />
Notice the additional phrase "sme8contribs," in the command line.<br />
<br />
Another example is as follows:<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
==Template for testing==<br />
<br />
=== not working===<br />
please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, and write in the wiki you tested it and it fails.<br /><br />
{{Tip box|the title of your bug should look to "'''sme9contribs:'''Can't locate esmith/FormMagick/Panel/passwordopt.pm" for example.}}<br />
BROKEN with your signature (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* bugs : [[bugzilla:NUMBER]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error :<br />
* workaround :<br />
* tested beyond installation : yes / no<br />
<br />
=== working===<br />
write here it works, with the following information :<br /><br />
<br />
WORKS with your signature. (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes / no<br />
<br />
Then please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, to ask to push the contribs to sme9contribs.<br /><br />
<br />
{{Tip box|The title of your bug should be for example "'''first import to sme9 tree [smeserver-mediawiki]'''"}}<br />
<br />
=Contribs=<br />
<br />
List of Contribs being tested<br />
* [http://bugs.contribs.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=SME+Contribs&format=table&action=wrap&version=9beta Bugs related to contribs in SME 9]<br />
<br />
<br />
<br />
==Need to test==<br />
<br />
===smeserver-adv-samba===<br />
*[[Advanced_Samba]]<br />
<br />
===smeserver-affa===<br />
*[[Affa]]<br />
<br />
===smeserver-ajaxterm===<br />
*[[Ajaxterm]]<br />
<br />
<br />
===smeserver-arpwatch===<br />
*[[arpwatch]]<br />
<br />
===smeserver-automysqlbackup===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:20, 15 January 2014 (MST)<br />
*wikipage : [[AutoMysqlBackup]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-automysqlbackup<br />
*version-release installed:<br />
automysqlbackup-3.0.RC6-3.el5.sme.noarch <br />
smeserver-automysqlbackup-3.0.RC6-3.el5.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8339]]<br />
<br />
===smeserver-awstats===<br />
*[[AWStats]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:06, 19 June 2014 (MDT) see [[bugzilla:8435]] and [[bugzilla:8450]]<br />
* wikipage : [[AWStats]]<br />
* to install : for now you have to install from epel, dag and smedev : yum --enablerepo=dag,epel,smedev install smeserver-awstats<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: awstats from dag, perl-Geo-IP from epel<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-BackupPC===<br />
<br />
*[[BackupPC]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:57, 21 April 2014 (MDT)<br />
* wikipage : [[BackupPC]]<br />
* to install :<br />
yum install smeserver-BackupPC --enablerepo=smecontribs,epel<br />
* version-release installed:<br />
smeserver-BackupPC-0.1-12.el5.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
see epel repository for backuppc<br />
BackupPC-3.3.0-2.el6.i686.rpm<br />
* tested beyond installation : yes<br />
it works as expected, it is my main network backup software. see [[bugzilla:8336]] for import to smecontribs<br />
<br />
===smeserver-bandwidthd===<br />
*[[bandwidthd]]<br />
<br />
===smeserver-bridge-interface===<br />
* [[BridgeInterface]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:19, 21 April 2014 (MDT)<br />
* wikipage : [[BridgeInterface]]<br />
* to install :<br />
yum --enablerepo=smecontribs,epel,dag install smeserver-bridge-interface<br />
* version-release installed:<br />
from sme9contribs<br />
smeserver-bridge-interface-0.2-1.el6.sme.noarch.rpm<br />
from base<br />
openssl098e-0.9.8e-17.el6.centos.2.i686.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
from epel,dag<br />
openvpn-2.3.1-3.el5.i386.rpm<br />
pkcs11-helper-1.07-2.el5.1.i386.rpm<br />
* tested beyond installation : yes<br />
<br />
It works as expected except that we must use some dependencies from dag and epel, see [[bugzilla:8337]]<br />
<br />
===smeserver-bugzilla===<br />
* no wiki<br />
<br />
===smeserver-cacti===<br />
*[[cacti]]<br />
<br />
===smeserver-crontab_manager===<br />
*[[Crontab_Manager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:33, 19 June 2014 (MDT) see [[bugzilla:8412]]<br />
* wikipage : [[Crontab_Manager]]<br />
* to install : yum install smeserver-crontab_manager --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dansguardian===<br />
*[[Dansguardian]]<br />
<br />
<br />
===smeserver-dar2===<br />
*[[DAR2]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*to install :<br />
enable [[stephdl]]<br />
yum install --enablerepo=stephdl smeserver-dar2<br />
*version-release installed:<br />
smeserver-dar2-0.0.3-1.el6.sme.noarch <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8508]]<br />
<br />
There is a bug raised against the setting 'smbfs' allowed by this contribs to backup on a remote host. The smbfs is obsolete now by cifs, you have to use cifs instead of smbfs. see [[bugzilla:8519]]<br />
<br />
===smeserver-ddclient===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 06:30, 21 June 2014 (MDT)<br />
*wikipage : [[ddclient]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-ddclient<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[epel]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8338]]<br />
<br />
===smeserver-denyhosts===<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:52, 29 March 2015 (CEST) see [[bugzilla:8428]]<br />
* wikipage : [[Denyhosts]]<br />
* to install : yum install smeserver-denyhosts --enablerepo=smedev,smecontribs,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dimp===<br />
* [[Dimp]]<br />
<br />
===smeserver-diskusage===<br />
*[[Diskusage]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:37, 19 June 2014 (MDT) see [[bugzilla:8410]]<br />
* wikipage : [[Diskusage]]<br />
* to install : yum install smeserver-diskusage --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-durep===<br />
*[[durep]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:22, 21 June 2014 (MDT) see [[bugzilla:8454]]<br />
* wikipage : [[durep]]<br />
* to install : yum install smeserver-durep --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-durep-1.5.0-1<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] and [[epel]] repositories<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-egroupware===<br />
*[[egroupware]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:28, 24 June 2014 (MDT) see [[bugzilla:8438]] see [[bugzilla:8487]]<br />
* wikipage : [[egroupware]]<br />
* to install : yum install smeserver-egroupware --enablerepo=smedev,Server_eGroupWare,epel<br />
* version-release installed: <br />
smeserver-egroupware-1.8.6-1.el6.sme.noarch<br /><br />
<br />
eGroupware-1.8.007.20140512-5.1.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs: [[Server_eGroupWare]] repository and epel and smedev for now but see [[bugzilla:8438]], the bug is pending the release in smecontribs (9.0)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-ejabberd===<br />
*[[Ejabberd]]<br />
<br />
===smeserver-ezmlm-web===<br />
*[[Ezmlm]]<br />
<br />
===smeserver-fetchmail===<br />
WORKS --[[User:Eastend99|Eastend99]] ([[User talk:Eastend99|talk]]) 14:36, 9 juni 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:47, 21 June 2014 (MDT) see [[bugzilla:8455]]<br />
*wikipage : [[Fetchmail]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-fetchmail<br />
*version-release installed:<br />
smeserver-fetchmail.noarch 0:1.6-1.el6.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, successfull retrieved e-mail<br />
<br />
===smeserver-freepbx===<br />
*[[FreePBX]]<br />
<br />
===smeserver-geoip===<br />
*[[GeoIP]]<br />
<br />
===smeserver-gollem===<br />
* no wiki, Horde plugin<br />
<br />
===smeserver-groupmembers-panel===<br />
*[[Groupmembers_Panel]]<br />
<br />
===smeserver-htbwshaper===<br />
*[[Wondershaper]] (need update)<br />
please see [[Qos]] this contrib is no longer maintained<br />
<br />
===smeserver-hwinfo===<br />
*[[Hardware Info]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*wikipage : [[Hardware Info]]<br />
*to install :<br />
enable [[stephdl]] and [[dag]]<br />
yum install --enablerepo=stephdl,dag smeserver-hwinfo<br />
*version-release installed:<br />
smeserver-hwinfo-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[dag]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8506]]<br />
<br />
===smeserver-hylafax===<br />
*[[HylaFax]]<br />
<br />
===smeserver-isoqlog===<br />
*[[isoqlog]]<br />
<br />
===smeserver-jeta===<br />
* no wiki<br />
<br />
===smeserver-kplaylist===<br />
*[[KPlaylist]]<br />
<br />
===smeserver-kronolith===<br />
*[[Kronolith]]<br />
<br />
===smeserver-lazy_admin_tools===<br />
*[[Lazy_Admin_Tools]]<br />
* works as is<br />
* to install <br />
yum --enablerepo=sme8contribs,smecontribs install smeserver-lazy_admin_tools<br />
--[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 04:04, 22 January 2015 (CET)<br />
<br />
===smeserver-madsonic===<br />
*[[Madsonic]]<br />
<br />
===smeserver-mailman===<br />
*[[Mailman]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:01, 20 June 2014 (MDT) see [[bugzilla:8453]]<br />
* wikipage : [[Mailman]]<br />
* to install : yum install smeserver-mailman --enablerepo=stephdl<br />
* version-release installed: mailman.x86_64 3:2.1.12-25.el6.sme smeserver-mailman.noarch 0:1.5.0-1.el6.sme<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] repository<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailsorting===<br />
*[[mailsorting]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:29, 23 June 2014 (MDT) see [[bugzilla:8465]]<br />
* wikipage : [[mailsorting]]<br />
* to install : yum install smeserver-mailsorting --enablerepo=stephdl,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: perl-Unicode-IMAPUtf7 (dag)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailstats===<br />
*[[mailstats]]<br />
Brian Read - 28Jan14 and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:35, 23 September 2014 (CEST) still in smedev but the bug is verified see [[bugzilla:8445]]<br />
* Installed ok.<br />
* tested beyond installation : only to the extent that it works with no data!! However it is pure perl, so I am not expecting it to fail<br />
Someone could build an RPM.<br />
tested beyond installation : Yes --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:56, 23 June 2014 (MDT)<br />
<br />
===smeserver-mimp===<br />
* [[Mimp]]<br />
<br />
===smeserver-mnemo===<br />
*[[Mnemo]]<br />
<br />
===smeserver-mod_dav===<br />
*[[DAV]]<br />
<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:35, 19 June 2014 (MDT) see [[bugzilla:8340]]<br />
* wikipage : [[DAV]]<br />
* to install : yum install smeserver-mod_dav --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mod_deflate===<br />
*[[mod_deflate]]<br />
<br />
===smeserver-mod_python===<br />
*[[Mod_Python]]<br />
<br />
===smeserver-nag===<br />
*[[Nag]]<br />
<br />
===smeserver-nagios===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-backup===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-nrpe===<br />
*[[Nagios_NRPE]]<br />
<br />
===smeserver-nagios-nsca===<br />
*[[Nagios_NSCA]]<br />
<br />
===smeserver-nagios-plugins-mysql===<br />
*[[Nagios]]<br />
<br />
===smeserver-nfs===<br />
*[[NFS]]<br />
<br />
===smeserver-oats===<br />
*[[Oats]]<br />
<br />
===smeserver-ocsinventory===<br />
*[[OCS_Inventory]]<br />
<br />
===smeserver-openoffice-portable===<br />
*[[OpenOffice_for_Windows]]<br />
<br />
===smeserver-openvpn-bridge===<br />
*[[OpenVPN_Bridge]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:11, 21 April 2014 (MDT)<br />
* wikipage : [[OpenVPN_Bridge]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-openvpn-bridge<br />
* version-release installed:<br />
perl-Net-OpenVPN-Manage-0.02-2.el6.sme.noarch.rpm<br />
perl-Net-Telnet-3.03-11.el6.noarch.rpm<br />
smeserver-openvpn-bridge-2.1-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes<br />
all rpms are available in sme9contribs<br />
<br />
===smeserver-openvpn-s2s===<br />
*[[OpenVPN_SiteToSite]]<br />
<br />
===smeserver-password===<br />
<br />
Work see [[bugzilla:8137]]<br />
<br />
* wikipage : [[Password]]<br />
* to install :<br />
yum install --enablerepo=smecontribs smeserver-password<br />
* version-release tried:<br />
smeserver-password-1.0.0-32.el5.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
all in smecontribs<br />
* error :<br />
* workaround : see [[bugzilla:8137]]<br />
* tested beyond installation : YES<br />
<br />
===smeserver-phpki=== <br />
*[[PHPki]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:25, 21 April 2014 (MDT)<br />
* wikipage : [[PHPki]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-phpki<br />
* version-release installed:<br />
php-process-5.3.3-27.el6_5.i686.rpm <br />
phpki-0.82-16.el6.sme.noarch.rpm<br />
smeserver-phpki-0.2-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
nothing at all<br />
* tested beyond installation : yes<br />
all rpms are in sme9contribs tree<br />
<br />
===smeserver-phpldapadmin===<br />
*[[Phpldapadmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:14, 21 June 2014 (MDT)-- see [[bugzilla:8456]]<br />
* wikipage : [[Phpldapadmin]]<br />
* to install : yum install smeserver-phpldapadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpmyadmin===<br />
*[[PHPMyAdmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:38, 19 June 2014 (MDT) see [[bugzilla:8413]]<br />
* wikipage : [[PHPMyAdmin]]<br />
* to install : yum install smeserver-phpmyadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpsysinfo===<br />
*[[Phpsysinfo]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:41, 21 June 2014 (MDT)<br />
*wikipage : [[Phpsysinfo]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-phpsysinfo<br />
*version-release installed: smeserver-phpsysinfo-3.1.13<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpvirtualbox===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[Phpvirtualbox]]<br />
*to install :<br />
yum install --enablerepo=stephdl,virtualbox smeserver-virtualbox smeserver-phpvirtualbox<br />
*version-release installed:<br />
smeserver-phpvirtualbox.noarch 0:4.3.0-10.el5.sme<br />
smeserver-virtualbox.noarch 0:4.3.0-5.el5.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: Virtualbox is in the virtualbox repository<br />
You have to install dkms but it is in the relevant epel repository<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpwebftp===<br />
*[[PhpWebFtp]]<br />
<br />
===smeserver-popfile===<br />
*[[popfile]]<br />
<br />
===smeserver-postgresql===<br />
*[[Postgres]] ?? should update this wiki page<br />
<br />
===smeserver-print-monitor===<br />
*[[LPRng print queue monitor]]<br />
<br />
*to install :<br />
yum install smeserver-print-monitor --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
*add template line<br />
nano /etc/e-smith/templates/etc/httpd/conf/httpd.conf/90e-smithAccess40LPRng<br />
add line : AuthBasicProvider external<br />
<br />
<Directory /var/www/html/LPRng><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<Directory /var/www/html/LPRng/admin><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<br />
*You should run this command<br />
signal-event console-save<br />
*or<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* tested Ecureuil<br />
<br />
===smeserver-qmHandle===<br />
*[[Qmhandle_mail_queue_manager]]<br />
WORKING --[[User:pmstewart|pmstewart]] ([[User talk:pmstewart|talk]]) 16:36, 7 October 2014 (MDT)<br />
<br />
Tested on Windows 8.1 all udpates installed in VirtualBox in production test server.<br />
<br />
*wiki-page: [[Qmhandle_mail_queue_manager]]<br />
*install: Add sme8contribs to yum as per testing critera<br />
*command: yum install smeserver-qmHandle --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version: smeserver-qmHandle.noarch 0:1.4-4.el5.sme<br />
*dependencies: no dependencies required<br />
*tested beyond install: yes - all server manager panel actions appear to work correctly<br />
<br />
===smeserver-qpsmtpd-spamassassinlevelstars===<br />
*[[Email#X-Spam-Level_Header_in_Email_Messages]]<br />
<br />
===smeserver-raidmonitor===<br />
*[[raidmonitor]]<br />
obsolete<br />
<br />
===smeserver-rdiff-backup===<br />
*[[rdiff-backup]]<br />
<br />
===smeserver-remoteuseraccess===<br />
*[[remoteuseraccess]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:17, 21 June 2014 (MDT)<br />
* wikipage : [[remoteuseraccess]]<br />
* to install : yum install smeserver-remoteuseraccess --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in smecontribs<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-rkhunter===<br />
*[[rkhunter]]<br />
<br />
===smeserver-roundcube===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[RoundCube]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-roundcube<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-sane===<br />
*[[SANE]]<br />
*WORKS<br />
*to install :<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version-release installed:<br />
smeserver-sane-0.1-7.el5.sme.noarch (sme8contribs)<br />
*dependencies<br />
sane-backends-1.0.21-3.el6.x86_64 (base)<br />
sane-backends-libs-1.0.21-3.el6.x86_64 (base)<br />
xinetd-2.3.14-39.el6_4.x86_64 (base)<br />
smeserver-xinetd-0.1-1.el5.sme.noarch (sme8contribs)<br />
*tested by Ecureuil<br />
<br />
===smeserver-sarg===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sarg]] & [[bugzilla:8174]]<br />
* to install : yum install smeserver-sarg --enablerepo=stephdl<br />
* version-release installed: smeserver-sarg-2.3.1-1 sarg-2.3.1<br />
* dependencies not in smeos,smeaddons,smecontribs: sarg-2.3.1 smeserver-sarg-2.3.1-1<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] repository<br />
<br />
===smeserver-shared-folders===<br />
*[[SharedFolders]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 10:35, 27 March 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:41, 21 June 2014 (MDT)<br />
* wikipage : [[SharedFolders]], see also [http://forums.contribs.org/index.php/topic,50325.msg253425.html#msg253425 this] forum post<br />
* to install : <br />
yum --enablerepo=smecontribs install smeserver-shared-folders<br />
* version-release installed: <br />
smeserver-shared-folders noarch 0.3-2.el6.sme smecontribs<br />
* dependencies not in smeos,smeaddons,smecontribs: <br />
smeserver-mod_dav noarch 1.0-1.el5.sme smecontribs <br />
* tested beyond installation : shared folder creation works, local and public access not tested<br />
<br />
===smeserver-sitemaker===<br />
*[[SME_Site_Maker]]<br />
<br />
===smeserver-sme8admin===<br />
*[[Sme8admin]]<br />
obsoletes; see sme9admin<br />
<br />
===smeserver-sme9admin===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sme9admin]]<br />
* to install : yum install smeserver-sme9admin --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-sme9admin-1.5-12<br />
* dependencies not in smeos,smeaddons,smecontribs: hddtemp<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] and [[epel]] repositories<br />
<br />
===smeserver-smf===<br />
WORKS --[[User:Mercyh|Mercyh]] 29 April 2015<br />
* wikipage: [[SMF]]<br />
* to install: This install is more complex as the rpm was never moved to SME8contribs repo this means you will need to setup the SME7contribs repo<br />
you would then install with : yum --enablerepo=sme7contribs install smeserver--smf<br />
* dependencies: no dependencies needed<br />
* tested beyond installation: yes in production on SME9 64bit server<br />
<br />
<br />
<br />
===smeserver-subsonic===<br />
*[[Subsonic]]<br />
<br />
===smeserver-subversion===<br />
*[[subversion]]<br />
<br />
===smeserver-sysmon===<br />
*[[sysmon]]<br />
<br />
===smeserver-tftp-server===<br />
*[[Tftp_server]]<br />
<br />
===smeserver-theaddressbook===<br />
*[[The Address Book]]<br />
<br />
===smeserver-thinclient===<br />
*[[Thinclient]]<br />
Warning: The contrib allows to specify the TFTP server as "Self". This worked well under SME7 but not under SME8. To get this working under SME8, we had to choose the SME server's IP address to achieve the same result as "self" otherwise the clients cannot find/load from the TFTP server. We have reported this as bug 6542 for the contrib but with this workaround, the contrib is working well under SME8. <br />
Bug has been reported as work for me, so please comment on it if you can replicate.<br />
<br />
===smeserver-transmission===<br />
Works see [[bugzilla:8134]]<br />
<br />
* wikipage : [[transmission]]<br />
* to install :<br />
yum install --enablerepo=stephdl smeserver-transmission<br />
* version-release tried: smeserver-transmission-0.0.2-1.el6.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs: in stephdl<br />
transmission-2.76-1geekery.x86_64.rpm<br />
transmission-cli-2.76-1geekery.x86_64.rpm<br />
transmission-common-2.76-1geekery.x86_64.rpm<br />
transmission-daemon-2.76-1geekery.x86_64.rpm <br />
libevent2-2.0.10-1geekery.x86_64.rpm<br />
<br />
* tested beyond installation : Go :)<br />
<br />
===smeserver-tw-logonscript===<br />
*[[Smeserver-tw-logonscript]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 12:05, 26 June 2014 (CET) * wikipage : [[Smeserver-tw-logonscript]], <br />
<br />
BROKEN<br />
installs correctly, server manager panel is not working.<br />
<br />
<br />
* bugs : [[bugzilla:8471]]<br />
* to install : <br />
yum --enablerepo=sme8contribs install smeserver-tw-logonscript<br />
* version-release installed: <br />
smeserver-tw-logonscript noarch 1.3-21.el5.sme sme8contribs 44 k<br />
<br />
* tested beyond installation :<br />
Internal Server Error<br />
The server encountered an internal error or misconfiguration and was unable to complete your request.<br />
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.<br />
More information about this error may be available in the server error log.<br />
<br />
Unable to locate the source of the error from /var/log logfiles.<br />
<br />
===smeserver-unjunkmgr===<br />
*[[Sme-unjunkmgr]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:07, 25 April 2014 (MDT)<br />
* bugs : [[bugzilla:8353]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
# rpm -qa smeserver-unjunkmgr<br />
smeserver-unjunkmgr-2.1-3.el5.sme.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : see bug report<br />
* tested beyond installation : broken<br />
<br />
===smeserver-updates===<br />
*[[Smeserver-updates]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:17, 23 June 2014 (MDT) see [[bugzilla:8463]]<br />
* wikipage : [[Smeserver-updates]]<br />
* to install : yum install Smeserver-updates --enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-usbdisksmanager===<br />
*[[Disk_Manager]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:56, 12 October 2014 (CEST)<br />
* wikipage : [[Disk_Manager]]<br />
* bugs : [[bugzilla:8597]]<br />
* to install : http://mirror.de-labrusse.fr/Sme-Server/smeserver-usbdisksmanager/<br />
* version-release tried: smeserver-usbdisksmanager-1.0-3.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : not for the moment<br />
* tested beyond installation : no<br />
<br />
===smeserver-userpanel===<br />
*[[UserManager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:14, 23 June 2014 (MDT) see [[bugzilla:8464]]<br />
* wikipage : [[UserManager]]<br />
* to install : yum install smeserver-userpanel enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-userpanels===<br />
*[http://www.dungog.net/wiki/Usermanager#Change_password Smeserver-userpanels] , needs wiki page at contribs<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:55, 29 March 2015 (CEST)<br />
* wikipage : TO DO<br />
* to install : yum install smeserver-userpanels enablerepo=smecontribs,stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-UserWebSpace===<br />
* no wiki page<br />
<br />
===smeserver-vacation===<br />
*[[Vacation]]<br />
<br />
===smeserver-virtualbox===<br />
see [[SME9.0_Contribs_QA#smeserver-phpvirtualbox]]<br />
<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-wbl===<br />
* bug: [[bugzilla:8521]]<br />
* Installation fails as some Template2Expand fragment directives clash with those from qpsmtpd.<br />
*[[Email#Email_WBL_server_manager_panel]]<br />
<br />
===smeserver-webconsole===<br />
*[[webconsole]]<br />
<br />
===smeserver-webshare===<br />
*[[Webshare]] <br />
<br />
===smeserver-wordpress===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:38, 15 January 2014 (MST)<br />
*wikipage : [[wordpress]] see [[bugzilla:8451]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-wordpress<br />
*version-release installed:<br />
smeserver-wordpress-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in epel<br />
php-IDNA_Convert-0.8.0-1.el6.noarch 1/8 <br />
php-simplepie-1.3.1-3.el6.noarch 2/8 <br />
php-process-5.3.3-27.el6_5.x86_64 3/8 <br />
1:enchant-1.5.0-4.el6.x86_64 4/8 <br />
php-enchant-5.3.3-27.el6_5.x86_64 5/8 <br />
php-PHPMailer-5.2.2-1.el6.noarch 6/8 <br />
wordpress-3.8-1.el6.noarch <br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-xinetd===<br />
*[[xinetd]]<br />
===smeserver-zarafa-unix===<br />
*[[Zarafa_on_SME_9]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:46, 19 June 2014 (MDT) see [[bugzilla:7383]]<br />
* wikipage : [[Zarafa_on_SME_9]]<br />
* to install : please see How to install directly in the [[Zarafa_on_SME_9|wikipage]] <br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: All Zarafa RPM's must be downloaded, extracted and installed using "yum localinstall". See Wiki page for detailed instructions.<br />
* tested beyond installation : Yes<br />
<br />
== Won't be ported to SME9 ==<br />
===smeserver-vmware-server===<br />
vmware server is not supported anymore please consider using virtualbox, or KVM...</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME9.0_Contribs_QA&diff=27714
SME9.0 Contribs QA
2015-04-29T14:44:33Z
<p>Mercyh: /* Need to test */</p>
<hr />
<div>=Version 9 beta3 Contrib testing=<br />
This document lists Contribs that, need to be tested or have had been tested running under SME 9<br />
<br />
Contribs should work if they are perl or php based (unless php53 deprecated some functions needed) . Some binary applications will work as well.<br />
<br />
Contribs using perl modules might be broken due to change of path<br />
<br />
Please also see [[Contribs Bugreport]]<br />
<br />
==Test guidelines==<br />
Considerations_before_installing advises that Contribs for SME 9 have not yet been released, this is to avoid dev workload diagnosing bugs caused by contribs.<br />
<br />
Please don't post SME 9 bugs unless you can replicate the bug with the contrib removed or isolated.<br />
<br />
{{Note box|If you have suggestions, issues or solutions for a contrib, please post them in bugzilla {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}} }}<br />
<br />
==Setup==<br />
During the transition from SME8 to SME9, contrib packages will be migrated to the SME9 contrib repository. If the contrib is not yet in the SME8 Contrib repository and an entry in this Q&A suggests it will install properly then you will need to install the contrib from the SME8 repository.<br />
<br />
Check to see if you already have the sme8contribs repository set up using the command:<br />
db yum_repositories show sme8contribs<br />
If it returns nothing then you will need to create a repo named sme8contribs, which points to the SME 8 smecontribs repo<br />
<br />
<br />
db yum_repositories set sme8contribs repository \<br />
Name 'SME 8 - contribs' \<br />
MirrorList 'http://mirrorlist.contribs.org/mirrorlist/smecontribs-8' \<br />
GPGCheck yes \<br />
Visible no \<br />
status disabled<br />
<br />
signal-event yum-modify<br />
yum clean all<br />
<br />
<br />
{{Note box|'''now you will need to add the package from sme8contribs and smecontribs to resolve some problems of dependencies...'''}}<br />
<br />
{{Note box|'''you might also consider to add some external repo such as [[dag]] and [[epel]]...'''}}<br />
<br />
<br />
The following shows an example of how to install a contrib from the SME 8 repo:<br />
<br />
yum '''--enablerepo=sme8contribs,smecontribs''' install smeserver-openvpn-s2s<br />
<br />
Notice the additional phrase "sme8contribs," in the command line.<br />
<br />
Another example is as follows:<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
==Template for testing==<br />
<br />
=== not working===<br />
please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, and write in the wiki you tested it and it fails.<br /><br />
{{Tip box|the title of your bug should look to "'''sme9contribs:'''Can't locate esmith/FormMagick/Panel/passwordopt.pm" for example.}}<br />
BROKEN with your signature (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* bugs : [[bugzilla:NUMBER]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error :<br />
* workaround :<br />
* tested beyond installation : yes / no<br />
<br />
=== working===<br />
write here it works, with the following information :<br /><br />
<br />
WORKS with your signature. (<nowiki>--~~~~</nowiki>)<br />
* wikipage : [[smeserver-contrib]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes / no<br />
<br />
Then please open a bug {{BugzillaFileBug|product=SME%20Contribs|component=|summary=|comment=|title=against the contrib.}}, to ask to push the contribs to sme9contribs.<br /><br />
<br />
{{Tip box|The title of your bug should be for example "'''first import to sme9 tree [smeserver-mediawiki]'''"}}<br />
<br />
=Contribs=<br />
<br />
List of Contribs being tested<br />
* [http://bugs.contribs.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=SME+Contribs&format=table&action=wrap&version=9beta Bugs related to contribs in SME 9]<br />
<br />
<br />
<br />
==Need to test==<br />
<br />
===smeserver-adv-samba===<br />
*[[Advanced_Samba]]<br />
<br />
===smeserver-affa===<br />
*[[Affa]]<br />
<br />
===smeserver-ajaxterm===<br />
*[[Ajaxterm]]<br />
<br />
<br />
===smeserver-arpwatch===<br />
*[[arpwatch]]<br />
<br />
===smeserver-automysqlbackup===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:20, 15 January 2014 (MST)<br />
*wikipage : [[AutoMysqlBackup]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-automysqlbackup<br />
*version-release installed:<br />
automysqlbackup-3.0.RC6-3.el5.sme.noarch <br />
smeserver-automysqlbackup-3.0.RC6-3.el5.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8339]]<br />
<br />
===smeserver-awstats===<br />
*[[AWStats]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:06, 19 June 2014 (MDT) see [[bugzilla:8435]] and [[bugzilla:8450]]<br />
* wikipage : [[AWStats]]<br />
* to install : for now you have to install from epel, dag and smedev : yum --enablerepo=dag,epel,smedev install smeserver-awstats<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: awstats from dag, perl-Geo-IP from epel<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-BackupPC===<br />
<br />
*[[BackupPC]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:57, 21 April 2014 (MDT)<br />
* wikipage : [[BackupPC]]<br />
* to install :<br />
yum install smeserver-BackupPC --enablerepo=smecontribs,epel<br />
* version-release installed:<br />
smeserver-BackupPC-0.1-12.el5.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
see epel repository for backuppc<br />
BackupPC-3.3.0-2.el6.i686.rpm<br />
* tested beyond installation : yes<br />
it works as expected, it is my main network backup software. see [[bugzilla:8336]] for import to smecontribs<br />
<br />
===smeserver-bandwidthd===<br />
*[[bandwidthd]]<br />
<br />
===smeserver-bridge-interface===<br />
* [[BridgeInterface]]<br />
<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:19, 21 April 2014 (MDT)<br />
* wikipage : [[BridgeInterface]]<br />
* to install :<br />
yum --enablerepo=smecontribs,epel,dag install smeserver-bridge-interface<br />
* version-release installed:<br />
from sme9contribs<br />
smeserver-bridge-interface-0.2-1.el6.sme.noarch.rpm<br />
from base<br />
openssl098e-0.9.8e-17.el6.centos.2.i686.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
from epel,dag<br />
openvpn-2.3.1-3.el5.i386.rpm<br />
pkcs11-helper-1.07-2.el5.1.i386.rpm<br />
* tested beyond installation : yes<br />
<br />
It works as expected except that we must use some dependencies from dag and epel, see [[bugzilla:8337]]<br />
<br />
===smeserver-bugzilla===<br />
* no wiki<br />
<br />
===smeserver-cacti===<br />
*[[cacti]]<br />
<br />
===smeserver-crontab_manager===<br />
*[[Crontab_Manager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:33, 19 June 2014 (MDT) see [[bugzilla:8412]]<br />
* wikipage : [[Crontab_Manager]]<br />
* to install : yum install smeserver-crontab_manager --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dansguardian===<br />
*[[Dansguardian]]<br />
<br />
<br />
===smeserver-dar2===<br />
*[[DAR2]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*to install :<br />
enable [[stephdl]]<br />
yum install --enablerepo=stephdl smeserver-dar2<br />
*version-release installed:<br />
smeserver-dar2-0.0.3-1.el6.sme.noarch <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8508]]<br />
<br />
There is a bug raised against the setting 'smbfs' allowed by this contribs to backup on a remote host. The smbfs is obsolete now by cifs, you have to use cifs instead of smbfs. see [[bugzilla:8519]]<br />
<br />
===smeserver-ddclient===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 06:30, 21 June 2014 (MDT)<br />
*wikipage : [[ddclient]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-ddclient<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[epel]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8338]]<br />
<br />
===smeserver-denyhosts===<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:52, 29 March 2015 (CEST) see [[bugzilla:8428]]<br />
* wikipage : [[Denyhosts]]<br />
* to install : yum install smeserver-denyhosts --enablerepo=smedev,smecontribs,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-dimp===<br />
* [[Dimp]]<br />
<br />
===smeserver-diskusage===<br />
*[[Diskusage]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:37, 19 June 2014 (MDT) see [[bugzilla:8410]]<br />
* wikipage : [[Diskusage]]<br />
* to install : yum install smeserver-diskusage --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-durep===<br />
*[[durep]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:22, 21 June 2014 (MDT) see [[bugzilla:8454]]<br />
* wikipage : [[durep]]<br />
* to install : yum install smeserver-durep --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-durep-1.5.0-1<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] and [[epel]] repositories<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-egroupware===<br />
*[[egroupware]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:28, 24 June 2014 (MDT) see [[bugzilla:8438]] see [[bugzilla:8487]]<br />
* wikipage : [[egroupware]]<br />
* to install : yum install smeserver-egroupware --enablerepo=smedev,Server_eGroupWare,epel<br />
* version-release installed: <br />
smeserver-egroupware-1.8.6-1.el6.sme.noarch<br /><br />
<br />
eGroupware-1.8.007.20140512-5.1.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs: [[Server_eGroupWare]] repository and epel and smedev for now but see [[bugzilla:8438]], the bug is pending the release in smecontribs (9.0)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-ejabberd===<br />
*[[Ejabberd]]<br />
<br />
===smeserver-ezmlm-web===<br />
*[[Ezmlm]]<br />
<br />
===smeserver-fetchmail===<br />
WORKS --[[User:Eastend99|Eastend99]] ([[User talk:Eastend99|talk]]) 14:36, 9 juni 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 05:47, 21 June 2014 (MDT) see [[bugzilla:8455]]<br />
*wikipage : [[Fetchmail]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-fetchmail<br />
*version-release installed:<br />
smeserver-fetchmail.noarch 0:1.6-1.el6.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
<br />
*tested beyond installation : yes<br />
Works as expected, successfull retrieved e-mail<br />
<br />
===smeserver-freepbx===<br />
*[[FreePBX]]<br />
<br />
===smeserver-geoip===<br />
*[[GeoIP]]<br />
<br />
===smeserver-gollem===<br />
* no wiki, Horde plugin<br />
<br />
===smeserver-groupmembers-panel===<br />
*[[Groupmembers_Panel]]<br />
<br />
===smeserver-htbwshaper===<br />
*[[Wondershaper]] (need update)<br />
please see [[Qos]] this contrib is no longer maintained<br />
<br />
===smeserver-hwinfo===<br />
*[[Hardware Info]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 08:36, 8 August 2014 (MDT)<br />
*wikipage : [[Hardware Info]]<br />
*to install :<br />
enable [[stephdl]] and [[dag]]<br />
yum install --enablerepo=stephdl,dag smeserver-hwinfo<br />
*version-release installed:<br />
smeserver-hwinfo-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]] and [[dag]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above. see [[bugzilla:8506]]<br />
<br />
===smeserver-hylafax===<br />
*[[HylaFax]]<br />
<br />
===smeserver-isoqlog===<br />
*[[isoqlog]]<br />
<br />
===smeserver-jeta===<br />
* no wiki<br />
<br />
===smeserver-kplaylist===<br />
*[[KPlaylist]]<br />
<br />
===smeserver-kronolith===<br />
*[[Kronolith]]<br />
<br />
===smeserver-lazy_admin_tools===<br />
*[[Lazy_Admin_Tools]]<br />
* works as is<br />
* to install <br />
yum --enablerepo=sme8contribs,smecontribs install smeserver-lazy_admin_tools<br />
--[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 04:04, 22 January 2015 (CET)<br />
<br />
===smeserver-madsonic===<br />
*[[Madsonic]]<br />
<br />
===smeserver-mailman===<br />
*[[Mailman]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:01, 20 June 2014 (MDT) see [[bugzilla:8453]]<br />
* wikipage : [[Mailman]]<br />
* to install : yum install smeserver-mailman --enablerepo=stephdl<br />
* version-release installed: mailman.x86_64 3:2.1.12-25.el6.sme smeserver-mailman.noarch 0:1.5.0-1.el6.sme<br />
* dependencies not in smeos,smeaddons,smecontribs: [[stephdl]] repository<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailsorting===<br />
*[[mailsorting]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:29, 23 June 2014 (MDT) see [[bugzilla:8465]]<br />
* wikipage : [[mailsorting]]<br />
* to install : yum install smeserver-mailsorting --enablerepo=stephdl,dag<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: perl-Unicode-IMAPUtf7 (dag)<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mailstats===<br />
*[[mailstats]]<br />
Brian Read - 28Jan14 and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 16:35, 23 September 2014 (CEST) still in smedev but the bug is verified see [[bugzilla:8445]]<br />
* Installed ok.<br />
* tested beyond installation : only to the extent that it works with no data!! However it is pure perl, so I am not expecting it to fail<br />
Someone could build an RPM.<br />
tested beyond installation : Yes --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:56, 23 June 2014 (MDT)<br />
<br />
===smeserver-mimp===<br />
* [[Mimp]]<br />
<br />
===smeserver-mnemo===<br />
*[[Mnemo]]<br />
<br />
===smeserver-mod_dav===<br />
*[[DAV]]<br />
<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:35, 19 June 2014 (MDT) see [[bugzilla:8340]]<br />
* wikipage : [[DAV]]<br />
* to install : yum install smeserver-mod_dav --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-mod_deflate===<br />
*[[mod_deflate]]<br />
<br />
===smeserver-mod_python===<br />
*[[Mod_Python]]<br />
<br />
===smeserver-nag===<br />
*[[Nag]]<br />
<br />
===smeserver-nagios===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-backup===<br />
*[[Nagios]]<br />
<br />
===smeserver-nagios-nrpe===<br />
*[[Nagios_NRPE]]<br />
<br />
===smeserver-nagios-nsca===<br />
*[[Nagios_NSCA]]<br />
<br />
===smeserver-nagios-plugins-mysql===<br />
*[[Nagios]]<br />
<br />
===smeserver-nfs===<br />
*[[NFS]]<br />
<br />
===smeserver-oats===<br />
*[[Oats]]<br />
<br />
===smeserver-ocsinventory===<br />
*[[OCS_Inventory]]<br />
<br />
===smeserver-openoffice-portable===<br />
*[[OpenOffice_for_Windows]]<br />
<br />
===smeserver-openvpn-bridge===<br />
*[[OpenVPN_Bridge]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 13:11, 21 April 2014 (MDT)<br />
* wikipage : [[OpenVPN_Bridge]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-openvpn-bridge<br />
* version-release installed:<br />
perl-Net-OpenVPN-Manage-0.02-2.el6.sme.noarch.rpm<br />
perl-Net-Telnet-3.03-11.el6.noarch.rpm<br />
smeserver-openvpn-bridge-2.1-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* tested beyond installation : yes<br />
all rpms are available in sme9contribs<br />
<br />
===smeserver-openvpn-s2s===<br />
*[[OpenVPN_SiteToSite]]<br />
<br />
===smeserver-password===<br />
<br />
Work see [[bugzilla:8137]]<br />
<br />
* wikipage : [[Password]]<br />
* to install :<br />
yum install --enablerepo=smecontribs smeserver-password<br />
* version-release tried:<br />
smeserver-password-1.0.0-32.el5.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
all in smecontribs<br />
* error :<br />
* workaround : see [[bugzilla:8137]]<br />
* tested beyond installation : YES<br />
<br />
===smeserver-phpki=== <br />
*[[PHPki]]<br />
'''WORKS''' --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:25, 21 April 2014 (MDT)<br />
* wikipage : [[PHPki]]<br />
* to install :<br />
yum --enablerepo=smecontribs install smeserver-phpki<br />
* version-release installed:<br />
php-process-5.3.3-27.el6_5.i686.rpm <br />
phpki-0.82-16.el6.sme.noarch.rpm<br />
smeserver-phpki-0.2-1.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
nothing at all<br />
* tested beyond installation : yes<br />
all rpms are in sme9contribs tree<br />
<br />
===smeserver-phpldapadmin===<br />
*[[Phpldapadmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:14, 21 June 2014 (MDT)-- see [[bugzilla:8456]]<br />
* wikipage : [[Phpldapadmin]]<br />
* to install : yum install smeserver-phpldapadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpmyadmin===<br />
*[[PHPMyAdmin]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:38, 19 June 2014 (MDT) see [[bugzilla:8413]]<br />
* wikipage : [[PHPMyAdmin]]<br />
* to install : yum install smeserver-phpmyadmin --enablerepo=stephdl,epel<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in [[stephdl]] and [[epel]] repo<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-phpsysinfo===<br />
*[[Phpsysinfo]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:41, 21 June 2014 (MDT)<br />
*wikipage : [[Phpsysinfo]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-phpsysinfo<br />
*version-release installed: smeserver-phpsysinfo-3.1.13<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpvirtualbox===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[Phpvirtualbox]]<br />
*to install :<br />
yum install --enablerepo=stephdl,virtualbox smeserver-virtualbox smeserver-phpvirtualbox<br />
*version-release installed:<br />
smeserver-phpvirtualbox.noarch 0:4.3.0-10.el5.sme<br />
smeserver-virtualbox.noarch 0:4.3.0-5.el5.sme <br />
*dependencies not in smeos,smeaddons,smecontribs: Virtualbox is in the virtualbox repository<br />
You have to install dkms but it is in the relevant epel repository<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-phpwebftp===<br />
*[[PhpWebFtp]]<br />
<br />
===smeserver-popfile===<br />
*[[popfile]]<br />
<br />
===smeserver-postgresql===<br />
*[[Postgres]] ?? should update this wiki page<br />
<br />
===smeserver-print-monitor===<br />
*[[LPRng print queue monitor]]<br />
<br />
*to install :<br />
yum install smeserver-print-monitor --enablerepo=sme8contribs --enablerepo=smecontribs<br />
<br />
*add template line<br />
nano /etc/e-smith/templates/etc/httpd/conf/httpd.conf/90e-smithAccess40LPRng<br />
add line : AuthBasicProvider external<br />
<br />
<Directory /var/www/html/LPRng><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<Directory /var/www/html/LPRng/admin><br />
...<br />
AuthType Basic<br />
AuthBasicProvider external <--<br />
AuthExternal pwauth<br />
require user admin $lprusers<br />
</Directory><br />
<br />
*You should run this command<br />
signal-event console-save<br />
*or<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* tested Ecureuil<br />
<br />
===smeserver-qmHandle===<br />
*[[Qmhandle_mail_queue_manager]]<br />
WORKING --[[User:pmstewart|pmstewart]] ([[User talk:pmstewart|talk]]) 16:36, 7 October 2014 (MDT)<br />
<br />
Tested on Windows 8.1 all udpates installed in VirtualBox in production test server.<br />
<br />
*wiki-page: [[Qmhandle_mail_queue_manager]]<br />
*install: Add sme8contribs to yum as per testing critera<br />
*command: yum install smeserver-qmHandle --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version: smeserver-qmHandle.noarch 0:1.4-4.el5.sme<br />
*dependencies: no dependencies required<br />
*tested beyond install: yes - all server manager panel actions appear to work correctly<br />
<br />
===smeserver-qpsmtpd-spamassassinlevelstars===<br />
*[[Email#X-Spam-Level_Header_in_Email_Messages]]<br />
<br />
===smeserver-raidmonitor===<br />
*[[raidmonitor]]<br />
obsolete<br />
<br />
===smeserver-rdiff-backup===<br />
*[[rdiff-backup]]<br />
<br />
===smeserver-remoteuseraccess===<br />
*[[remoteuseraccess]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:17, 21 June 2014 (MDT)<br />
* wikipage : [[remoteuseraccess]]<br />
* to install : yum install smeserver-remoteuseraccess --enablerepo=smecontribs<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in smecontribs<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-rkhunter===<br />
*[[rkhunter]]<br />
<br />
===smeserver-roundcube===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:37, 15 January 2014 (MST)<br />
*wikipage : [[RoundCube]]<br />
*to install :<br />
yum install --enablerepo=stephdl smeserver-roundcube<br />
*version-release installed:<br />
<br />
*dependencies not in smeos,smeaddons,smecontribs: all in [[stephdl]]<br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-sane===<br />
*[[SANE]]<br />
*WORKS<br />
*to install :<br />
yum install smeserver-usbdisksmanager --enablerepo=sme8contribs --enablerepo=smecontribs<br />
*version-release installed:<br />
smeserver-sane-0.1-7.el5.sme.noarch (sme8contribs)<br />
*dependencies<br />
sane-backends-1.0.21-3.el6.x86_64 (base)<br />
sane-backends-libs-1.0.21-3.el6.x86_64 (base)<br />
xinetd-2.3.14-39.el6_4.x86_64 (base)<br />
smeserver-xinetd-0.1-1.el5.sme.noarch (sme8contribs)<br />
*tested by Ecureuil<br />
<br />
===smeserver-sarg===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sarg]] & [[bugzilla:8174]]<br />
* to install : yum install smeserver-sarg --enablerepo=stephdl<br />
* version-release installed: smeserver-sarg-2.3.1-1 sarg-2.3.1<br />
* dependencies not in smeos,smeaddons,smecontribs: sarg-2.3.1 smeserver-sarg-2.3.1-1<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] repository<br />
<br />
===smeserver-shared-folders===<br />
*[[SharedFolders]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 10:35, 27 March 2014 (CET) and --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:41, 21 June 2014 (MDT)<br />
* wikipage : [[SharedFolders]], see also [http://forums.contribs.org/index.php/topic,50325.msg253425.html#msg253425 this] forum post<br />
* to install : <br />
yum --enablerepo=smecontribs install smeserver-shared-folders<br />
* version-release installed: <br />
smeserver-shared-folders noarch 0.3-2.el6.sme smecontribs<br />
* dependencies not in smeos,smeaddons,smecontribs: <br />
smeserver-mod_dav noarch 1.0-1.el5.sme smecontribs <br />
* tested beyond installation : shared folder creation works, local and public access not tested<br />
<br />
===smeserver-sitemaker===<br />
*[[SME_Site_Maker]]<br />
<br />
===smeserver-sme8admin===<br />
*[[Sme8admin]]<br />
obsoletes; see sme9admin<br />
<br />
===smeserver-sme9admin===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 11:46, 16 December 2014 (CET)<br />
* wikipage : [[Sme9admin]]<br />
* to install : yum install smeserver-sme9admin --enablerepo=stephdl,epel<br />
* version-release installed: smeserver-sme9admin-1.5-12<br />
* dependencies not in smeos,smeaddons,smecontribs: hddtemp<br />
* tested beyond installation : yes but you have to enable the [[stephdl]] and [[epel]] repositories<br />
<br />
===smeserver-smf===<br />
WORKS --Mercyh 29 April 2015<br />
* wikipage: [[SMF]]<br />
* to install: This install is more complex as the rpm was never moved to SME8contribs repo this means you will need to setup the SME7contribs repo<br />
you would then install with : yum --enablerepo=sme7contribs install smeserver--smf<br />
* dependencies: no dependencies needed<br />
* tested beyond installation: yes in production on SME9 64bit server<br />
<br />
<br />
<br />
===smeserver-subsonic===<br />
*[[Subsonic]]<br />
<br />
===smeserver-subversion===<br />
*[[subversion]]<br />
<br />
===smeserver-sysmon===<br />
*[[sysmon]]<br />
<br />
===smeserver-tftp-server===<br />
*[[Tftp_server]]<br />
<br />
===smeserver-theaddressbook===<br />
*[[The Address Book]]<br />
<br />
===smeserver-thinclient===<br />
*[[Thinclient]]<br />
Warning: The contrib allows to specify the TFTP server as "Self". This worked well under SME7 but not under SME8. To get this working under SME8, we had to choose the SME server's IP address to achieve the same result as "self" otherwise the clients cannot find/load from the TFTP server. We have reported this as bug 6542 for the contrib but with this workaround, the contrib is working well under SME8. <br />
Bug has been reported as work for me, so please comment on it if you can replicate.<br />
<br />
===smeserver-transmission===<br />
Works see [[bugzilla:8134]]<br />
<br />
* wikipage : [[transmission]]<br />
* to install :<br />
yum install --enablerepo=stephdl smeserver-transmission<br />
* version-release tried: smeserver-transmission-0.0.2-1.el6.sme.noarch.rpm <br />
* dependencies not in smeos,smeaddons,smecontribs: in stephdl<br />
transmission-2.76-1geekery.x86_64.rpm<br />
transmission-cli-2.76-1geekery.x86_64.rpm<br />
transmission-common-2.76-1geekery.x86_64.rpm<br />
transmission-daemon-2.76-1geekery.x86_64.rpm <br />
libevent2-2.0.10-1geekery.x86_64.rpm<br />
<br />
* tested beyond installation : Go :)<br />
<br />
===smeserver-tw-logonscript===<br />
*[[Smeserver-tw-logonscript]]<br />
[[User:Easren99|Eastend99]] ([[User talk:Eastend99|talk]]) 12:05, 26 June 2014 (CET) * wikipage : [[Smeserver-tw-logonscript]], <br />
<br />
BROKEN<br />
installs correctly, server manager panel is not working.<br />
<br />
<br />
* bugs : [[bugzilla:8471]]<br />
* to install : <br />
yum --enablerepo=sme8contribs install smeserver-tw-logonscript<br />
* version-release installed: <br />
smeserver-tw-logonscript noarch 1.3-21.el5.sme sme8contribs 44 k<br />
<br />
* tested beyond installation :<br />
Internal Server Error<br />
The server encountered an internal error or misconfiguration and was unable to complete your request.<br />
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.<br />
More information about this error may be available in the server error log.<br />
<br />
Unable to locate the source of the error from /var/log logfiles.<br />
<br />
===smeserver-unjunkmgr===<br />
*[[Sme-unjunkmgr]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:07, 25 April 2014 (MDT)<br />
* bugs : [[bugzilla:8353]]<br />
* to install : yum install smeserver-contrib --enablerepo=sme8contribs,smecontribs,epel<br />
* version-release tried:<br />
# rpm -qa smeserver-unjunkmgr<br />
smeserver-unjunkmgr-2.1-3.el5.sme.noarch<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : see bug report<br />
* tested beyond installation : broken<br />
<br />
===smeserver-updates===<br />
*[[Smeserver-updates]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 10:17, 23 June 2014 (MDT) see [[bugzilla:8463]]<br />
* wikipage : [[Smeserver-updates]]<br />
* to install : yum install Smeserver-updates --enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all is in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-usbdisksmanager===<br />
*[[Disk_Manager]]<br />
BROKEN --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:56, 12 October 2014 (CEST)<br />
* wikipage : [[Disk_Manager]]<br />
* bugs : [[bugzilla:8597]]<br />
* to install : http://mirror.de-labrusse.fr/Sme-Server/smeserver-usbdisksmanager/<br />
* version-release tried: smeserver-usbdisksmanager-1.0-3.el6.sme.noarch.rpm<br />
* dependencies not in smeos,smeaddons,smecontribs:<br />
* error : see bug report<br />
* workaround : not for the moment<br />
* tested beyond installation : no<br />
<br />
===smeserver-userpanel===<br />
*[[UserManager]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 12:14, 23 June 2014 (MDT) see [[bugzilla:8464]]<br />
* wikipage : [[UserManager]]<br />
* to install : yum install smeserver-userpanel enablerepo=stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-userpanels===<br />
*[http://www.dungog.net/wiki/Usermanager#Change_password Smeserver-userpanels] , needs wiki page at contribs<br />
* WORKS --[[User:Unnilennium|Unnilennium]] ([[User talk:Unnilennium|talk]]) 20:55, 29 March 2015 (CEST)<br />
* wikipage : TO DO<br />
* to install : yum install smeserver-userpanels enablerepo=smecontribs,stephdl<br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: all in stephdl<br />
* tested beyond installation : Yes<br />
<br />
===smeserver-UserWebSpace===<br />
* no wiki page<br />
<br />
===smeserver-vacation===<br />
*[[Vacation]]<br />
<br />
===smeserver-virtualbox===<br />
see [[SME9.0_Contribs_QA#smeserver-phpvirtualbox]]<br />
<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-wbl===<br />
* bug: [[bugzilla:8521]]<br />
* Installation fails as some Template2Expand fragment directives clash with those from qpsmtpd.<br />
*[[Email#Email_WBL_server_manager_panel]]<br />
<br />
===smeserver-webconsole===<br />
*[[webconsole]]<br />
<br />
===smeserver-webshare===<br />
*[[Webshare]] <br />
<br />
===smeserver-wordpress===<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 17:38, 15 January 2014 (MST)<br />
*wikipage : [[wordpress]] see [[bugzilla:8451]]<br />
*to install :<br />
yum install --enablerepo=stephdl,epel smeserver-wordpress<br />
*version-release installed:<br />
smeserver-wordpress-1.2-1.el6.sme.noarch<br />
*dependencies not in smeos,smeaddons,smecontribs: all in epel<br />
php-IDNA_Convert-0.8.0-1.el6.noarch 1/8 <br />
php-simplepie-1.3.1-3.el6.noarch 2/8 <br />
php-process-5.3.3-27.el6_5.x86_64 3/8 <br />
1:enchant-1.5.0-4.el6.x86_64 4/8 <br />
php-enchant-5.3.3-27.el6_5.x86_64 5/8 <br />
php-PHPMailer-5.2.2-1.el6.noarch 6/8 <br />
wordpress-3.8-1.el6.noarch <br />
*tested beyond installation : yes<br />
Works as expected, just follow instructions as per the wiki above<br />
<br />
===smeserver-xinetd===<br />
*[[xinetd]]<br />
===smeserver-zarafa-unix===<br />
*[[Zarafa_on_SME_9]]<br />
WORKS --[[User:Stephdl|Stephdl]] ([[User talk:Stephdl|talk]]) 15:46, 19 June 2014 (MDT) see [[bugzilla:7383]]<br />
* wikipage : [[Zarafa_on_SME_9]]<br />
* to install : please see How to install directly in the [[Zarafa_on_SME_9|wikipage]] <br />
* version-release installed:<br />
* dependencies not in smeos,smeaddons,smecontribs: All Zarafa RPM's must be downloaded, extracted and installed using "yum localinstall". See Wiki page for detailed instructions.<br />
* tested beyond installation : Yes<br />
<br />
== Won't be ported to SME9 ==<br />
===smeserver-vmware-server===<br />
vmware server is not supported anymore please consider using virtualbox, or KVM...</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=27279
Netkeeper Remote Server Monitor
2015-01-22T15:27:38Z
<p>Mercyh: /* Installation */</p>
<hr />
<div>===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
===Installation===<br />
Download the installation files from [http://gert.co.za/contribs/NRSM/ here].<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
**''Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Upgrading from v0.2/v0.3 TO v0.5===<br />
* Version 0.3 shows the date and time of the last successful Affa backup job instead of just ''SUCCESS'' or ''FAILURE''.<br />
<br />
# Download ''NRSM_Update_v0.2_to_v0.5.zip''<br />
# Unzip and replace the old NRSM.exe with the new one.<br />
# Download and replace ''post.pl'' on the servers with Affa backup monitoring.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
----<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration:Monitoring]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=12358
Netkeeper Remote Server Monitor
2009-02-23T21:12:45Z
<p>Mercyh: /* Upgrading from v0.2 to v0.3 */</p>
<hr />
<div><br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
**''Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Upgrading from v0.2/v0.3 TO v0.5===<br />
* Version 0.3 shows the date and time of the last successful Affa backup job instead of just ''SUCCESS'' or ''FAILURE''.<br />
<br />
# Download ''NRSM_Update_v0.2_to_v0.5.zip''<br />
# Unzip and replace the old NRSM.exe with the new one.<br />
# Download and replace ''post.pl'' on the servers with Affa backup monitoring.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=12357
Netkeeper Remote Server Monitor
2009-02-23T21:08:21Z
<p>Mercyh: </p>
<hr />
<div><br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
**''Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Upgrading from v0.2 to v0.3===<br />
* Version 0.3 shows the date and time of the last successful Affa backup job instead of just ''SUCCESS'' or ''FAILURE''.<br />
<br />
# Download ''NRSM_Update_v0.2_to_v0.3.zip''<br />
# Unzip and replace the old NRSM.exe with the new one.<br />
# Download and replace ''post.pl'' on the servers with Affa backup monitoring.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server:Documentation:FAQ&diff=12105
SME Server:Documentation:FAQ
2009-01-02T14:37:08Z
<p>Mercyh: /* Password Strength Checking */</p>
<hr />
<div>{{Languages|SME_Server:Documentation:FAQ}}<br />
<br />
==Frequently Asked Questions==<br />
<br />
This Section lists ''Frequently Asked Questions'' (FAQ) for SME 7. Problems many people run into installing SME 7 for the first time or upgrading to later versions are found here.<br />
<br />
If your question isn't listed here, it's possible it's a ''Rarely Asked Question'' (RAQ), in which case you'll be better off searching for answers in [http://bugs.contribs.org Bugzilla]. <br />
<br />
===Installation troubles===<br />
====Installer prompts for installation file location====<br />
Problems have been reported installing SME Server off a PATA CD-ROM drive. The system is able to boot from the CD-ROM drive but after that you get prompted by a message to specify the location where the installation image can be found. This might either mean that the disk is not readable or the CD-ROM drive is not recognized.<br />
If you have validated the disk and are sure that the disk passes you might try to add the all-generic-ide option to the boot prompt before starting the installer like this:<br />
linux all-generic-ide<br />
<br />
===Yum Updates===<br />
==== Which repositories should be enabled====<br />
<br />
You should have the following repositories enabled (blue)<br />
CentOS - os<br />
CentOS - updates<br />
SME Server - addons<br />
SME Server - extras<br />
SME Server - os<br />
SME Server - updates.<br />
<br />
DO NOT enable '''SME Server - updates testing''' which is considered beta, unless<br />
* it is a TEST server NOT a production server or<br />
* you want to be part of a bug-testing group.<br />
<br />
Additionally <br />
* '''SME Server - test''' is considered alpha <br />
* '''SME Server - dev''' contains automatically built rpms. It contains lots of experimental,<br />
incomplete and mutually incompatible packages.<br />
<br />
{{Warning box|msg=If upgrading from a system prior to 7.1 update 1, ie a 7.1 CD install or earlier,<br />
you need to ensure you have the latest versions of the following rpms prior to applying the rest of the updates.<br />
This speeds up install process and avoids updates from centos that may be ahead of the distribution.<br />
<br />
yum update dbus dbus-glib smeserver-support smeserver-yum yum yum-plugin-fastest-mirror python-sqlite <br />
signal-event post-upgrade; signal-event reboot<br />
}}<br />
<br />
{{Note box|A system installed from the SME 7.1 CD will have the 5 repositories above enabled. A system installed from the SME 7.0 iso and updated to 7.1 or later will only have the 3 SME Server repositories enabled. After updating from SME 7.0 to SME 7.1.x you should enable the ''Centos - os'' & ''Centos - updates'' repositories in server-manager.<br />
}}<br />
<br />
*For another way to reset the repositories to the default see [[:Adding_Software#Restoring_Default_Yum_Repositories]]<br />
<br />
====Reconfigure / post-upgrade and reboot====<br />
*When is a post-upgrade and reboot required?<br />
The server manager yum installer has no way of determining whether<br />
any configuration files will change if all are re-expanded or to know which<br />
binaries have changed (or use libraries which have now changed) and therefore<br />
need to be restarted. The only '''safe''' option is to reconfigure and restart<br />
everything.<br />
<br />
After clicking '''Reconfigure''' check the Status message and that the server does actually reboot.<br />
Rarely circumstances arise that prevent the reconfigure from triggering. If so run the following,<br />
<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
====Updating from SME 7.x to SME 7.2====<br />
See [[:Updating_to_SME_7.2#Yum_Update]]<br />
<br />
<br />
<br />
====General====<br />
*Please Wait - Yum Running (prereposetup)<br />
This means Yum is working out what updates are available.<br />
Occasionally such as when large sets of updates are released this could take 10+ minutes to complete<br />
<br />
*Yum doesn't seem to be working correctly. What do I do now?<br />
If for some reason you can't get yum to work correctly, try:<br />
yum clean metadata<br />
or possibly 'yum clean all'<br />
yum update<br />
<br />
*Fix for 'Metadata file does not match checksum'<br />
Typical error message<br />
http://apt.sw.be/fedora/3/en/i386/dag/repodata/primary.xml.gz: <br />
[Errno -1] Metadata file does not match checksum Trying other mirror.<br />
Error: failure: repodata/primary.xml.gz from dag: [Errno 256] No more mirrors to try.<br />
<br />
To flush the up stream proxies, using wget, run:<br />
<br />
wget --cache=off http://apt.sw.be/fedora/3/en/i386/dag/repodata/filelists.xml.gz<br />
wget --cache=off http://apt.sw.be/fedora/3/en/i386/dag/repodata/primary.xml.gz<br />
wget --cache=off http://apt.sw.be/fedora/3/en/i386/dag/repodata/repomd.xml<br />
yum update<br />
<br />
* An unclean shutdown during a system update can put the system into a state where it's difficult to recover.<br />
find all the duplicate rpm's<br />
rpm -qa | sort | less <br />
Then remove all the duplicate rpm's<br />
rpm -e --nodeps rpmname<br />
Install the newest rpms <br />
yum install rpmname<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
* Where can I go to learn more about yum, and about how SME uses it?<br />
[[:Adding_Software ]], man yum, http://linux.duke.edu/projects/yum/<br />
<br />
====Adding, removing or disabling repositories ====<br />
<br />
*What is the recommended way to add other yum repositories<br />
The following code uses the dag repository as an example and sets the status to disabled. <br />
The repository is configured to be used via the command line with the --enablerepo= option <br />
{{Repository|dag}}<br />
<br />
*How do I remove yum repositories<br />
<br />
db yum_repositories delete repositoryname<br />
signal-event yum-modify<br />
<br />
*How do I disable a repository to allow future use via command line with the --enablerepo= option<br />
<br />
db yum_repositories repositoryname setprop status disabled<br />
signal-event yum-modify<br />
<br />
====Other popular repositories====<br />
<br />
http://wiki.contribs.org/Category:Yum_Repository<br />
<br />
Be careful updating software from these repositories. Only update packages by name eg.<br />
yum update --enablerepo=reponame packagename<br />
<br />
Do not do a general update with the 3rd party repository enabled as it could update many packages that will overwrite SME versions.<br />
<br />
===Hardware Compatibility List===<br />
[http://wiki.contribs.org/KnownProblems#Hardware List of Hardware that known have problems with SME Server]<br />
<br />
Maintaining a complete HCL is difficult, <br />
the following links will give a indication of hardware being used by SME Servers and upstream providers<br />
<br />
*https://hardware.redhat.com/index.cgi<br />
*http://smolt.contribs.org<br />
*http://wiki.centos.org/HardwareList<br />
<br />
===Client Computers===<br />
<br />
*Samba trust relationships lost?<br />
This is a possible bug with an upgrade from SME6. After an upgrade, local workstations cannot log in. If you are experiencing this problem, please have a look at this bug for a fix, and provide followup: <br />
[https://sourceforge.net/tracker/index.php?func=detail&amp;aid=1234009&amp;group_id=96750&amp;atid=615772]<br />
<br />
<br />
*Windows XP Clients - Patch to logon to SME domain<br />
This patch can be used when Windows XP clients won't be able to log on to the SME Server domain. The registry patch is located here: <br />
http://servername/server-resources/regedit/winxplogon.reg<br />
Double click on the winxplogon.reg file and the settings will be added to the Windows Registry.<br />
<br />
<br />
*How to disable password caching on Windows 95/98/ME/2000 Clients?<br />
This patch can be used if you don't want Windows clients to remember password for shared folders on SME Server. The registry patch is located here: http://servername/server-resources/regedit/win98pwdcache.reg <br />
Just double click on the win98pwdcache.reg file and the settings will be added to the Windows Registry. <br />
<br />
'''Note'''<br />
Although the filename seems to indicate that this patch will only work for Windows 98, but it also works in Windows 95, Windows ME and Windows 2000.<br />
<br />
<br />
*LDAP Directory Gives MAPI_E_CALL_FAIL Errors on Outlook 2002 or Outlook 2003<br />
In Outlook 2002 or 2003 when someone tries to find a contact using the LDAP server, a message stating that "Unavailable critical extension" and then a second message saying "The search could not be completed. MAPI_E_CALL_FAIL" shows up and nothing shows up from the search. The directory works beautifully in Thunderbird 1.5 as well as Outlook 2000, but not 2002 or 2003. More information can be found here: [http://support.microsoft.com/default.aspx?scid=kb;en-us;555536&amp;sd=rss&amp;spid=2559] [http://bugs.contribs.org/show_bug.cgi?id=1406]<br />
<br />
<br />
*Where is the netlogon directory?<br />
The netlogon directory is located on the SMESERVER at: /home/e-smith/files/samba/netlogon<br />
It can also be found by a client computer at: \\servername\netlogon<br />
<br />
===Web Applications===<br />
*chmod 777<br />
<br />
Using 777 is always wrong (despite the fact that many howtos recommend it). 0770 is sufficient, as long as www is a member of the group owning the directory, and is safer.<br />
<br />
Use chown www /path/to/dir <br /><br />
and preferably put your app in /opt/app not in an ibay <br />
<br />
* Generic Instructions for Installing a Web Application<br />
http://wiki.contribs.org/Generic_WebApp_rpm<br />
<br />
*Wasn't mod_perl installed in previous versions? How do I install it?<br />
It may have been, but it was not used so it is no longer included. If you do want to install it do the following:<br />
<br />
'''Note'''<br />
The commands on a linux shell are case-sensitive, this means that Capital is not the same as capital.<br />
<br />
yum install mod_perl<br />
config setprop modPerl status enabled<br />
signal-event post-upgrade ; signal-event reboot<br />
<br />
*The directory structure is visible. How do I disable indexes in ibays?<br />
SME Server 6.0, 6.0.1, and 6.5 all had the following for the ibays/html directory - "Options Indexes Includes". This would indicate that indexes were allowed for html directories. In SME Server 7.0 this is made a parameter and it defaults to enabled to be compatible with SME Server releases before SME Server 7.0 installations. <br />
<br />
To disable indexes for an ibay in SME Server 7.0 do the following:<br />
<br />
db accounts setprop //ibayname// Indexes disabled <br />
signal-event ibay-modify //ibayname// <br />
<br />
This issue was first reported here: <br />
[[https://sourceforge.net/tracker/?func=detail&amp;atid=615772&amp;aid=1275351&amp;group_id=96750]]<br />
<br />
*I need to create (or install) a PHP application that needs access to the /tmp directory.<br />
db accounts setprop ibayname PHPBaseDir /tmp/:/home/e-smith/files/ibays/ibayname/<br />
signal-event ibay-modify ibayname<br />
<br />
By default if you have PHP code in an IBAY, it can only run in that IBAY. The above commands will allow PHP code in the IBAY to run outside of its installed directory. <br />
<br />
Here is a list of all the [[:DB_Variables_Configuration#Apache_server_ibay_specific_.28httpd-e-smith.29 | IBAY specific settings]]<br />
<br />
===Reset the root and admin password===<br />
<br />
1. Restart your server and at the beginning of the boot-up use the arrow keys to select the kernel you would like to boot into.<br />
<br />
2. Press A , to allow you to append parameters to your grub boot settings.<br />
<br />
3. Be careful not to change anything, only add the following after the A (Be sure to put a space before single):<br />
single<br />
4. Press enter. you will be presented with a prompt.<br />
<br />
5. At this prompt type the following two commands (each followed by a return). You will be asked to provide a new password. <br />
Reset both your root and your admin password and set them to the same value:<br />
passwd root<br />
passwd admin<br />
Reboot your server and everything should be okay now.<br />
<br />
<br />
===File Size Limitations===<br />
*Apache, the web server can only transfer or show files under 2G<br />
<br />
*Backup to USB Disk<br />
FAT32 only supports file size of <4GB. It is recommended that you format your external usb drives to ext3.<br />
<br />
<br />
===Domains===<br />
<br />
*When I create a DOMAIN, I don't see anything listed in the HOSTNAMES AND ADDRESSES panel for that DOMAIN.<br />
<br />
For a domain to be effective (for email or web), it needs to be configured as INTERNET DNS SERVERS (this is the default value). Since the domain resolves via INTERNET DNS SERVERS, no hostnames or addresses are created locally. For more info please visit the Administration Manual section regarding Domains: [[http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter13#Domains]]<br />
<br />
<br />
===Virus Scanning===<br />
*When you elect to nightly scan your server for viruses the current default is to scan /home/e-smith/files<br />
<br />
Note that early SME 7 Servers defaulted to /. <br />
<br />
Also you may want to scan under /opt if have contribs that store user data there<br />
<br />
the db property to change to the default <br />
config setprop clamav FilesystemScanFilesystems /home/e-smith/files<br />
or to scan different areas of the server is<br />
config setprop clamav FilesystemScanFilesystems "/home/e-smith/files /opt"<br />
<br />
<br />
*How do I exclude some directories from scanning<br />
Set the db value to exclude more directories<br />
<br />
The default<br />
config setprop clamav FilesystemScanExclude /proc,/sys,/usr/share,/var<br />
<br />
Change with<br />
config setprop clamav FilesystemScanExclude /proc,/sys,/usr/share,/var,/home/e-smith/files/ibays<br />
<br />
After any change, run the signal-event for expand and regenerate configuration files, and restart pertinent services<br />
<br />
signal-event clamav-update<br />
<br />
===Proxy Pass===<br />
<br />
*I want to pass some http requests to a server behind my SME Server or external to my site, how can I do this?<br />
<br />
You can set a ProxyPass directive that will pass certain requests to an internal or external server that hosts the domain to be proxypassed:<br />
db domains set proxypassdomain.com domain <br />
db domains setprop proxypassdomain.com Nameservers internet<br />
db domains setprop proxypassdomain.com ProxyPassTarget http://xxx.xxx.xxx.xxx/<br />
db domains setprop proxypassdomain.com TemplatePath ProxyPassVirtualHosts <br />
signal-event domain-create proxypassdomain.com<br />
where proxypassdomain.com is the domain name hosted on the internal or external server<br />
and http://xxx.xxx.xxx.xxx/ is the IP address of the internal or external server eg 192.168.1.20 or 122.456.12.171 (it must be the publicly accessible IP if an external server)<br />
<br />
<br />
To delete a ProxyPass directive that you previously set up:<br />
db domains delete proxypassdomain.com<br />
signal-event domain-delete proxypassdomain.com<br />
<br />
{{Note box|If you have added the internal or external server's domain name as a virtual domain on the SME Server, you must remove it prior to issuing these commands. The server-manager domains panel will show the proxy pass entry but you will not be able to edit it, see [[bugzilla:1612]].<br />
}}<br />
<br />
===Shell Access===<br />
*I need to give a user shell access to the SME Server.<br />
<br />
Shell access should only be provided to users who have a *need* for it and can be trusted. <br />
<br />
Before a user can have shell access Admin must enable ssh access at <br />
server-manager -> Security -> Remote Access<br />
<br />
You then enable shell access for a user by:<br />
db accounts setprop username Shell /bin/bash<br />
chsh -s /bin/bash username<br />
<br />
===Upgrading Server===<br />
*What's the best way to upgrade to a new server ?<br />
An article is written for this subject. Please visit: http://wiki.contribs.org/UpgradeDisk<br />
<br />
===Changing maximum Ibay, Account or Group name length===<br />
* How do I change the default maximum (12 characters) name length of an I-Bay, account or group?<br />
Enter following command on the console as root:<br />
/sbin/e-smith/db configuration set maxIbayNameLength xx<br />
/sbin/e-smith/db configuration set maxAcctNameLength xx<br />
/sbin/e-smith/db configuration set maxGroupNameLength xx<br />
where 'xx' is the new size e.g. 15.<br />
<br />
Followed by:<br />
/sbin/e-smith/signal-event console-save<br />
<br />
===Deletion of Users Ibays Groups===<br />
*I can't delete & create a user for some reason. What do I do now?<br />
If for some reason you can't delete & create a user, then first do:<br />
signal-event user-delete <username><br />
db accounts delete <username><br />
<br />
*I can't delete & create a ibay for some reason. What do I do now?<br />
If for some reason you can't delete & create a ibay, then first do:<br />
signal-event ibay-delete <ibayname><br />
db accounts delete <ibayname><br />
<br />
*I can't delete & create a group for some reason. What do I do now?<br />
If for some reason you can't delete & create a group, then first do:<br />
signal-event group-delete <groupname><br />
db accounts delete <groupname><br />
<br />
<br />
*I was looking in the home directory of a user and I see a hidden directory called ".junkmail". Do I need that? Can I delete it?<br />
Don't remove or rename .junkmail folders.<br />
<br />
===Password Strength Checking===<br />
*How can I change password strength & what do the strength settings mean?<br />
<br />
{{Warning box|It is strongly advised not to set the password strength setting to ''none'' as this will lower the security of your server significantly.}}<br />
<br />
{{Note box|PAM module requires passwords to be at least 6 characters long, so setting a password that is shorter than that may cause other problems later. SME server default settings enforce 7 character passwords.}}<br />
<br />
The following settings are available to specify the password strength on SME Server:<br />
<br />
{|<br />
! setting<br />
! explanation<br />
|- <br />
| ''strong'' <br />
| The password is passed through Cracklib for dictionary type word checking as well as requiring upper case, lower case, number, non alpha and a mimimum length of 7 characters.<br />
|- <br />
| ''normal''<br />
| The password requires upper case, lower case, number, non alpha and a minimum length of 7 characters.<br />
|- <br />
| ''none''<br />
| The password can be anything as no checking is done.<br />
Please note that "none" does not mean no password, it just means no password strength checking, so you can enter any (weak) password you want as long as it is at least 7 characters long.<br />
|}<br />
<br />
To set password strength do:<br />
config setprop passwordstrength Admin strengthvalue<br />
config setprop passwordstrength Users strengthvalue<br />
config setprop passwordstrength Ibays strengthvalue<br />
where strengthvalue is one of the entries listed in the table above.<br />
<br />
e.g. <br />
config setprop passwordstrength Users normal<br />
<br />
To review the current settings do:<br />
config show passwordstrength<br />
<br />
which should display something like:<br />
<br />
passwordstrength=configuration<br />
Admin=strong<br />
Ibays=strong<br />
Users=strong<br />
<br />
Alternatively, you can install the smeserver-password contrib discussed here: [[Password]]<br />
<br />
This contrib will let you configure password strength and ageing though a web panel in the server-manager.<br />
<br />
<br />
References:<br />
<ol></li><li>[https://sourceforge.net/tracker/?func=detail&atid=615772&&aid=1228269&group_id=96750 Old Bugtracker on SF.net: Sme7a22 - user passwords]<br />
</li><li>[[Bugzilla:161]]</li><br />
<li>[[Bugzilla:2686]]</li></ol><br />
<br />
===Hard Drives, RAID's, USB Hard Drives===<br />
*How should I setup my hard-drives?<br />
We never recommend anything other than a '''single disk install''' or '''multiple disks of the same type'''. Anything else and you are following an unrecommended setup and you will need to navigate for yourself. Repeat, we never recommend anything other than a '''single disk install''' or '''multiple disks of the same type'''. If you're thinking of doing anything else (setup your own partitions), read this section again.<br />
<br />
*How should I setup my RAID?<br />
A full article on RAID is found here: [[:Raid]]<br />
<br />
<br />
*I want to use a hardware RAID. What do you suggest?<br />
Please see the notes in the RAID article: [[:Raid#Raid_Notes]]<br />
<br />
<br />
*How do I recover an SME Server with lvm drives<br />
A full article on the recovery method is found here: [[:Recovering_SME_Server_with_lvm_drives]]<br />
<br />
<br />
*I'm installing a RAID 5 but it seems to take a long time. Is there something wrong?<br />
RAID 5 systems (those with 3+ disks) can take a long time during and after the install for everything to sync. Reportedly, it takes almost 2 hours before the disks finally finish syncing on 4 X 80GB disks.<br />
<br />
<br />
*If I boot my SMESERVER with a USB hard drive attached, it recognizes the drive. However, after unplugging the drive, then replugging, it no longer exists. Any ideas why?<br />
Reportedly, some external usb hd's must be completely powered up before connecting the usb cable.<br />
<br />
<br />
*If I boot my SMESERVER with a USB hard drive attached, it doesn't recognize the drive. Any workarounds for this?<br />
Some USB drives need to be plugged twice into the server to be recognized.<br />
<br />
===Backups & Restores===<br />
*AIT-1 Backup: buffer unreliable<br />
An AIT-1 is unreliable if used with variable block size. Set the setting<br />
config setprop flexbackup TapeBlocksize 512<br />
AIT-2, DAT and LTO seem to work well with variable block size.<br />
<br />
<br />
*Slow tape backup performance may be improved by changing Flex backup settings<br />
config setprop flexbackup Blocksize 256<br />
config setprop flexbackup BufferMegs 16<br />
<br />
<br />
*In the ADMIN CONSOLE, there is an option to BACKUP TO USB but there are no restore options.<br />
The RESTORE option is only visible on a new install. If you missed this during install, you can<br />
config set PasswordSet no <br />
signal-event post-upgrade; signal-event reboot <br />
<br />
During reboot reconfiguration process you should see the new restore via USB backup option. <br />
-NOW plug in the usb drive (Do not plug in the usb drive until you reach this point).<br />
-pick YES or RESTORE (or whatever is presented to you)<br />
<br />
<br />
===Supervised Services===<br />
*Many services on SME are supervised, to see which are type<br />
ps ax |grep runsv<br />
To control them read the sv manual<br />
man sv<br />
<br />
*it seems that "sv u http-e-smith" gives no errors, even if the service fails to restart, so you need to use "sv s httpd-e-smith" to check if it fails (example: due to a httpd.conf error)<br />
<br />
This is just the way that runsv (part of the runit package) works. The "sv u http-e-smith"<br />
only sends a message to runsv saying that we want the service to be up. <br />
runsv then will keep trying to get the service running.<br />
<br />
<br />
===Server-Manager===<br />
*I can't access the server-manager. What do I do now?<br />
There are many reasons why you wouldn't be to access the server-manager. First try:<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
If you still can't access, there are reports that a certificates mis-match might have occurred after update. In that case:<br />
rm /home/e-smith/ssl.key/*.key<br />
rm /home/e-smith/ssl.pem/*.pem<br />
rm /home/e-smith/ssl.crt/*.crt<br />
signal-event domain-modify; signal-event reboot<br />
<br />
<br />
*I used to access the SERVER-MANAGER with localhost:980 remotely via SSH tunnel and now I can't. What happened?<br />
This feature has been deprecated a long time and finally removed in V7.2<br />
<br />
If you really want to use this then forward 443 to localhost:443 and then use<br />
https://localhost/server-manager/<br />
<br />
<br />
*Using a ssh client, the /server-manager login screen is difficult to read<br />
The text is white, so you need to adjust your ssh client to use a dark background<br />
<br />
<br />
*I've renamed my server with the ADMIN CONSOLE. The old name appears under the SERVER-MANAGER, HOSTNAMES panel. It cannot be deleted as there are no MODIFY/REMOVE links.<br />
<br />
-login to the shell console<br />
-type: db hosts setprop <local.mycompany.local> static no<br />
-go to the HOSTNAMES & ADDRESSES panel and you should be able to modify/remove the name<br />
<br />
===Booting with SMP kernel after upgrade to version 7.2 from CD===<br />
*I've upgraded and now the SMP kernel isn't available. <br />
This is because when upgrading to 7.2 from CD, kernel modules are <br />
missing for SMP '''IF''' the output of "cat/proc/cpuinfo" <br />
does not show multiple processors. The SMP kernel, if not present, can be installed via yum using:<br />
Do:<br />
yum install kernel-smp kmod-ppp-smp kmod-slip-smp kmod-appletalk-smp<br />
signal-event post-upgrade<br />
signal-event reboot<br />
Details: http://bugs.contribs.org/show_bug.cgi?id=3095<br />
<br />
*I'm getting a kernel panic after upgrade from CD. What do I do now?<br />
When upgrading with a CD, the upgrade will rewrite the grub.conf file. As a result, any additional boot arguments (i.e. acpi=off) will be lost during upgrade. Please edit the grub.conf file.<br />
<br />
<br />
===Special Characters===<br />
*I get strange characters & letters when look at my file names.<br />
If you get filenames that look like: "éèÃ.txt" It's most likely because the SME server isn't understanding special characters you may be using. You can change it to understand special characters in filenames by:<br />
db configuration setprop smb UnixCharSet ISO8859-1<br />
expand-template /etc/smb.conf<br />
/etc/init.d/smb restart<br />
<br />
<br />
===Upstream proxy server configuration===<br />
<br />
*How do I configure a mandatory upstream proxy server, there used to be a panel in earlier versions of sme server, but it's missing in sme7.x<br />
<br />
config set SquidParent a.b.c.d<br />
config set SquidParentPort nnn<br />
signal-event post-upgrade<br />
signal-event reboot<br />
<br />
[The SquidParentPort setting is optional if the upstream proxy is on port 3128.]<br />
<br />
From http://forums.contribs.org/index.php?topic=32998.msg140512#msg140512<br />
<br />
<br />
===Memory usage and limits===<br />
<br />
*How much memory can sme server handle<br />
<br />
SME server currently (v7.3) supports 16GB of RAM, with a maximum of 3GB per process. These limits can easily be increased to 64GB total and 4GB per process by installing and running the "hugemem" variant of the kernel<br />
<br />
*Why does my sme server always seem to be using all the memory, there is no spare memory left<br />
<br />
Utilities such as top or htop always report that all available memory is being used.<br />
The Linux OS is designed to utilise all available memory all of the time. If other processes require more memory then it is made available to those processes. Fully utilising all the available memory is a good thing as it optimises the performanece of your server.<br />
<br />
*How can I tell if my sme server needs more memory<br />
<br />
Watch the availabe swap memory usage eg using top, htop or ps -aux. If swap memory usage regularly exceeds 50% of the available swap memory, then you should add more physical RAM to your system.<br />
Other indications that additional RAM is required are "out of memory" messages in log files, and at times the server becomes inactive for a period, often related to spam & virus scanning & high email loads.<br />
<br />
{{:Booting}}<br />
<br />
{{:Log_Files}}<br />
<br />
{{:Email}}<br />
<br />
{{:Firewall}}<br />
<br />
{{:MySQL}}<br />
<br />
==Later versions of applications==<br />
<br />
===Why does SME Server still not have PHP 5, MySql4, Apach2, xxx ===<br />
SME Server 7.x is based on Centos 4.x which in term is based on RedHat Enterprise Linux 4.x. Since the development team is limited in person and time, all work is done in spare time, we do not have the time to implement such big changes and cope with the maintenance of such work.<br />
<br />
===Is xxx on SME Server still safe to run? ===<br />
Yes, because security fixes and bug fixes are backported to the 4.x releases and they are propagated to the users as updates, for more information have a look at http://www.redhat.com/security/updates/backporting.<br />
<br />
===Can I install a later version of xxx===<br />
Yes, but you are then responsible for updates and possible conflicts with updates<br />
<br />
For example see this page for [[:PHP#PHP_5 PHP]] updates and warnings<br />
<br />
==Known Problems==<br />
<br />
{{Note box|This section is to be used to document problems that cannot or will not be fixed through development of SME Server 7. <br><br />
Please refer to the [[:KnownProblems]] page}}</div>
Mercyh
https://wiki.koozali.org/index.php?title=Password&diff=12074
Password
2008-12-31T16:26:10Z
<p>Mercyh: New page: {{Incomplete}} This is a placeholder page for the smeserver-password contrib. Category: Contrib Category: Administration</p>
<hr />
<div>{{Incomplete}} <br />
This is a placeholder page for the smeserver-password contrib.<br />
<br />
[[Category: Contrib]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server:Community:Forum&diff=12067
SME Server:Community:Forum
2008-12-30T14:43:25Z
<p>Mercyh: /* Use a descriptive title for your thread */</p>
<hr />
<div>==Forums==<br />
The forums can be found at http://forums.contribs.org.<br />
<br />
===Purpose===<br />
The forums are used for discussions on a variety of topics considering SME Server. Here you can discuss configurations, ask opinions and support that is not provided by the bugtracker. The forums is the place where users can help each other and exchange experiences and knowledge.<br />
{{Note box|The development team is also member of the forums but please report problems with SME Server in the bugtracker. <br />
<br />
If you have discovered a bug or a suspected bug, please submit the issue to the bug tracker and '''not''' to the forums. Discussions about the bug should be within the bug tracker. Once you have submitted the bug, you can reference it in the forum as information to others please ensure a link to the bug tracker is provided.}}<br />
It is appreciated that before posting in the forums you first read the manuals and try to search for you answer in the manuals, wiki, forums and bugtracker before posting a question in one of the forum boards.<br />
<br />
===Guidelines===<br />
{{Incomplete}}<br />
Before posting a question to the forums, we would ask that you take the time to read this post. Please also read the Where to Find Answers post.<br />
<br />
This information is provided to help you get answers to your questions more quickly. Everyone who provides answers are volunteers and their time is valuable. Following the guidelines below will help them make the best use of that time to aid as many as possible including, of course, you.<br />
<br />
====Post your question to the correct forum====<br />
This may seem obvious but please try to ensure you post your question to the correct forum and in the correct section (eg, for SME Server 6.x, SME Server 7.x or SME Contribs etc). If you are unsure in which forum your question belongs, please do NOT double post in multiple forums and use the General Discussion board. Most of us read ALL the forums so we will see your question. Double posting will result in 1) you being asked not to double post as opposed to being provided with an answer and 2) multiples posts being locked by a moderator where inappropriate.<br />
<br />
====Use a descriptive title for your thread====<br />
Firstly, post your own thread - do not hijack someone else's thread, even if you think your question is related. You may post a link to any related threads that you feel are appropriate.<br />
<br />
Use a descriptive title for your thread. This is your one chance to advertise what it is you require help with and persuade people to actually read and potentially answer your question. Do not SHOUT and your question is not urgent (at least not to anyone else). Please do not use txt speak or exclamation marks (!!!!).<br />
<br />
Bad example:<br />
<br />
Urgent: pls hlp, can't get it to work!!!!!!<br />
<br />
This tells us nothing other than it's urgent to you and that something isn't working. It is unlikely to even attract views, let alone answers. If you can't get your title right, what hope do we have that you've actually asked a coherent question in such a way that we may be able to help.<br />
<br />
Better example:<br />
<br />
Installed SME 7.4, need help getting Network to connect (Dell Integrated Broadcom Nic).<br />
<br />
Now we know what you've done and those who have dealt with Broadcom Nics will know that it's an issue where they can possibly help. (This also holds for other hardware such as video cards and hard drives. Someone might ignore a subject of network doesn't work but answer a post of realtec card not working if they've had experience dealing with that particular card.)<br />
<br />
====Composing your question====<br />
Again, do not SHOUT and your question is not urgent (at least not to anyone else). Please do not use txt speak and no excessive exclamation marks. Do use good spelling, grammar and punctuation, and split your post up as appropriate into separate paragraphs. We acknowledge that although English is the preferred language of the forums, it is not everyone's first or native language. You do not need to apologize if English is not your native language, just do the best that you can to clearly and concisely describe your problem.<br />
<br />
Before posting your question, first think about what your question is. If you don't know what your question is and how to articulate it, it is highly unlikely anyone else will be able to provide a reply. We don't have crystal balls & we can't read minds and make sure you actually ask a question.<br />
<br />
Bad example:<br />
<br />
Q: My nic doesn't work!<br />
A: That's a shame, but thank you for sharing it with us. Did you have a question?<br />
<br />
Better example:<br />
<br />
Q: My nic isn't detected after a default installation of SME Server. Please could anyone assist me in getting it working?<br />
<br />
Don't ask questions that can be answered with yes or no, unless you want a yes or no answer, as that's what you'll most likely get.<br />
<br />
Bad example:<br />
<br />
Q: I can't get Foo to work. Has anyone else managed to get this working?<br />
A: Yes.<br />
<br />
====Ask realistic questions====<br />
Saying you're totally new to Linux and asking how to set up a domain server to authenticate users, provide roaming profiles, file sharing and email services with spam and virus filtering to replace your current server provided by some other company demonstrates totally unrealistic expectations on your behalf. No one is going to be able to help you, as this is likely to be a long term project and not something you are going to achieve over the weekend by asking a couple of questions on a forum.<br />
<br />
====Provide the relevant information====<br />
Research your question or problem. You may find an answer is already provided. Demonstrating that you have researched your question by describing what you have previously done to try to resolve your problem is more likely to persuade a volunteer to help you than if you sit back and expect the answer to land on your plate.<br />
<br />
Provide as much useful information as possible to assist others in helping you solve your problem. We don't know what hardware/software you are running, or how you have configured your system unless you tell us. We also can not guess at what error message you may have received.<br />
<br />
If you have a hardware-related problem, please provide information about your hardware. We can not help answer questions like "help, my nic isn't working" without knowing what nic you have and what attempts you have made to configure it.<br />
<br />
Use commands such as lspci, lsmod, lsusb or dmidecode to gather information about your hardware and provide that in your post.<br />
<br />
If you have a software-related question, please provide as much relevant information about your configuration as possible. Provide the version numbers of any software you are using, post the configuration file for the package you are having problems with and check your logs for relevant errors, and post these too (only the relevant errors please, not the whole log file).<br />
<br />
If your question relates in any way to the kernel, please show us what kernel(s) you have installed and running by providing the output from the following commands:<br />
<br />
uname -a<br />
rpm -qa kernel* | sort<br />
<br />
This will help to speed up the process of getting your problem resolved and is likely the first information you will be asked for if you haven't provided it.<br />
<br />
====What to do if no one answers====<br />
Please wait for at least 24 hours. The volunteers on this forum live all over the world. If it's day time where you live, it's going to be night time somewhere else and the person able to answer your question may be sleeping, so give everyone a chance to read your question.<br />
<br />
If after 24 hours you haven't received any answers, then you may bump your thread by posting more information. By more information, we mean what you have tried during the last 24 hours to fix the problem. You have been trying to fix your problem, haven't you and not just waiting for someone else to fix it for you?<br />
<br />
====What to do once you have an answer====<br />
It would be nice to thank the member(s) who helped you. We are all the more inclined to help those who take the time to acknowledge the help they have received.<br />
<br />
Provide feedback as to what the solution was. This will help the next person with the same problem to identify the solution and so share this knowledge with others.<br />
<br />
Congratulations, now you have an answer to your problem, you have gained some valuable knowledge that, hopefully, you'll be willing to share when another Community member asks a similar question. Before you know it, you will be one of the people answering some of the questions, not just asking them. This is how a community works, by giving a little back occasionally. So once you have an answer we hope you'll stay around and become part of the Community.<br />
<noinclude>----<br />
[[Category:Help|Forum]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server:Community:Manual&diff=12066
SME Server:Community:Manual
2008-12-30T14:26:43Z
<p>Mercyh: /* Purpose */</p>
<hr />
<div>==Manuals==<br />
The manuals are located at [[:SME Server:Documentation]].<br />
<br />
===Purpose===<br />
The documentation section contains the manuals and is an extensive source of documentation. It is a must read for everyone who is willing to use SME Server. It may be large and overwhelming to you at first, but experience, over time, has proven that a lot of problems could have easily been solved or would not have existed if users would have read them.<br />
It is also worth your time to re-read the manual after working some time with SME Server as a lot of information that did not stick or did not seem interesting at first might very well be interesting once you gained experience with SME Server.<br />
{{Tip box|Although it may sound silly we advise you to read the manuals at least two times.}}<br />
<noinclude>----<br />
[[Category:Help|Manual]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server:Community:Manual&diff=12065
SME Server:Community:Manual
2008-12-30T14:25:46Z
<p>Mercyh: /* Purpose */</p>
<hr />
<div>==Manuals==<br />
The manuals are located at [[:SME Server:Documentation]].<br />
<br />
===Purpose===<br />
The documentation section contains the manuals and is an extensive source of documentation. It is a must read for everyone who is willing to use SME Server. It may be large and overwhelming to you at first, but experience, over time, has proven that a lot of problems could have easily been solved or would not have existed if users would have read them.<br />
It is also worth your time to re-read the manual after working some time with SME Server as a lot of information that did not stick or did not seem interesting at first might very well be interesting once you gained experience with SME Server.<br />
{{Tip box|Although it may sounds silly we advise you to read the manuals at least two times.}}<br />
<noinclude>----<br />
[[Category:Help|Manual]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server:Community&diff=12064
SME Server:Community
2008-12-30T14:24:26Z
<p>Mercyh: </p>
<hr />
<div>{{Languages}}<br />
==Before you dive in==<br />
Since SME Server is a community product, mainly powered by a small number of developers and a small crowd there is a large user community. There is a wide variety of communication media used and a lot of valuable information shared in this community. All people contributing donate their free time to this product and get nothing in return as SME Server is free, as in beer.<br />
<br />
SME Server is a collaborative effort to create a secure and solid server product based on Linux. Development is done by a small team of developers in their free and spare team. <br />
The community not only consists of the development team, but also of a very active community and has a lot of information sources and communication media.<br />
<br />
As it can be hard for new people to know what to expect from the community and/or where to put their information or ask their question we kindly ask you to carefully read this page as it tries to briefly describe what to expect where.<br />
{{Note box|As a general rule in the SME Server community we ask you to please try searching the information sources provided here before posting or asking for help. '''Please respect the value of people's time by investing effort on your own part before asking questions.''' Thanks very much on behalf of the SME Server community.}}<br />
{{:SME Server:Community:Manual}}<br />
{{:SME Server:Community:FAQ}}<br />
{{:SME Server:Community:Bugtracker}}<br />
{{:SME Server:Community:Wiki}}<br />
{{:SME Server:Community:Forum}}<br />
{{:SME Server:Community:Mailinglist}}</div>
Mercyh
https://wiki.koozali.org/index.php?title=Email&diff=10262
Email
2008-07-17T15:33:12Z
<p>Mercyh: /* Multiple users with the same name on different domains */</p>
<hr />
<div>==Email==<br />
===Spam===<br />
====Spamassassin====<br />
Set spamassassin for automatically delete junkmail.<br />
You can change the "days" that spamassassin sets to automatically delete junkmail, to delete after two months <br />
<br />
db configuration setprop spamassassin MessageRetentionTime 60 <br />
signal-event email-update <br />
<br />
<br />
The "Custom spam rejection level" will only work when "Spam sensitivity" is set to custom.<br />
<ol></li><li>Open server-manager.<br />
</li><li>Click e-mail in the navigation pane (left-hand side).<br />
</li><li>Click Change e-mail filtering settings.<br />
</li><li>Change "Spam sensitivity" to custom and adjust the settings to your liking.<br />
</li></ol><br />
<br />
This happens because by default, no mail (except for viruses) gets rejected without the admin doing something first.<br />
<br />
====='''X-Spam-Level Header in Email Messages'''=====<br />
SME does not create an X-Spam-Level header in processed email messages by default.<br />
<br />
To enable this capability:<br />
/usr/bin/yum install --enablerepo=smecontribs smeserver-qpsmtpd-spamassassinlevelstars<br />
signal-event email-update<br />
<br />
(Based on [[Bugzilla:3505]])<br />
<br />
=====Custom Rule Scores=====<br />
You can customize the score assigned by a specific Spamassassin rule (SARE_ADULT2 in this case) as follows:<br />
mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
echo "score SARE_ADULT2 20.000" >> 20localscores<br />
signal-event email-update<br />
<br />
You can now add additional tests and custom scores by editing the newly-created template fragment ''20localscores'' and adding new custom scores using:<br />
pico -w /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
Each custom score goes on its own line. If you enter a score surrounded by parentheses, the "custom" score will be added to the default score for the specified test (use ''score TEST_NAME (-1)'' to reduce the score for 'TEST_NAME' by 1) <br />
<br />
You can remove these customizations using: <br />
rm -f /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
<br />
References:<br />
* http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#scoring_options<br />
* http://spamassassin.apache.org/tests_3_2_x.html<br />
* http://www.rulesemporium.com/<br />
<br />
====Real-time Blackhole List (RBL)====<br />
Enabling RBL's <br><br />
RBL's are disabled by default to allow maximum accommodation (your ISP may be on a RBL & you may not know it). You can enable RBL's by:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
signal-event email-update<br />
<br />
You can see your RBL's by:<br />
config show qpsmtpd<br />
<br />
You can add to your RBL's by:<br />
config setprop qpsmtpd RBLList <rbl-list-name><br />
signal-event email-update<br />
<br />
Many will argue what's best but most would agree that you can set best-practice recommended settings by:<br />
config setprop qpsmtpd RBLList zen.spamhaus.org:whois.rfc-ignorant.org:dnsbl.njabl.org<br />
signal-event email-update<br />
<br />
Note: More information on this topic can be found here:<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#RHSBL_Servers]<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#DNSBL_Servers]<br />
<br />
====Server Only====<br />
Some of the spam filter rules cannot work unless the SMESERVER knows the external IP of the box. If you put a SMESERVER in server-only mode behind other firewalls, it will lose some of the anti-spam rules. For example, the rule that blocks attempts where spammers try "HELO a.b.c.d" where a.b.c.d is your external IP address.<br />
<br />
Unfortunately, many admins believe that port-forwarding SMTP provides additional security. It doesn't, it limits the SMESERVER's ability to apply some rules.<br />
<br />
<br />
====I want to enable GreyListing====<br />
GreyListing support is under the covers and can easily be enabled for those who know what they are doing. However, many experienced users found that they spent more time looking after the greylisting configuration than they received in benefit.<br />
<br />
====Setup Blacklists & Bayesian Autolearning====<br />
<br />
(Much of what follows has been shamelessly copied from the Sonoracomm howto)<br />
<br />
The default SME settings (as you can see [http://wiki.contribs.org/Email#Default_Plugin_Configuration here]) do not include DNSBL filtering, spam rejection, or (which is not obvious from the above) bayesian filtering in spamassassin to allow spamassassin to learn from received email and improve over time.<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set<br />
thresholds for the bayesian filter.<br />
<br />
config setprop spamassassin UseBayes 1<br />
config setprop spamassassin BayesAutoLearnThresholdSpam 4.00<br />
config setprop spamassassin BayesAutoLearnThresholdNonspam 0.10<br />
expand-template /etc/mail/spamassassin/local.cf<br />
sa-learn --sync --dbpath /var/spool/spamd/.spamassassin -u spamd<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes_*<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes.mutex<br />
chmod 640 /var/spool/spamd/.spamassassin/bayes_* <br />
config setprop qpsmtpd DNSBL enabled<br />
config setprop qpsmtpd RHSBL enabled<br />
config setprop spamassassin status enabled<br />
config setprop spamassassin RejectLevel 12<br />
config setprop spamassassin TagLevel 4<br />
config setprop spamassassin Sensitivity custom<br />
signal-event email-update<br />
<br />
These commands will:<br />
* enable spamassassin<br />
* configure spamassassin to reject any email with a score above 12<br />
* tag spam scored between 4 and 12 in the email header<br />
* enable bayesian filter<br />
* 'autolearn' as SPAM any email with a score above 4.00<br />
* 'autolearn' as HAM any email with a score below 0.10<br />
* enable RHSBL using the default SBLList. Note that rhsbl checking has been known to place a heavy burden on SME servers.<br />
* enable DNSBL using the default RBLList<br />
<br />
====The entire Sonoracomm howto from Google's text cache====<br />
* The Sonoracomm HowTo has been a very well regarded set of instructions for SME mail server configuration for quite a while.<br />
<br />
* This section was created during an extended outage of the Sonoracomm web server (in 2007?)<br />
<br />
* The Sonoracomm HowTo has been updated since this section was created, and is well worth examining. View the current version at: http://www.sonoracomm.com/index.php?option=com_content&task=view&id=49&Itemid=32<br />
<br />
* The content below has been modified to include changes suggested in the bug tracker and forums.<br />
<br />
* These instructions are aimed mostly at configuring SME as the only mail server, not for using SME with an internal mail server. (Specifically, LearnAsSpam.pl is harder to configure when using an internal mail server - you would have to develop a method for getting the unmarked SPAM into an IMAP folder directly on the SME server itself. Not impossible, but difficult!)<br />
<br />
'''SONORA COMMUNICATIONS, INC.'''<br />
<br />
This is a quick configuration howto, not an in-depth look at SpamAssassin. Much more can be done<br />
beyond this document, but this will take a big dent out of your spam and free up CPU cycles on your server.<br />
<br />
See 'More Information' at the end.<br />
<br />
'''SpamAssassin'''<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set thresholds for the bayesian filter.<br />
<nowiki>rpm -Uvh \<br />
http://mirror.contribs.org/smeserver/contribs/\<br />
michaelw/sme7/smeserver-spamassassin-features-0.0.2-0.noarch.rpm</nowiki><br />
<br />
This command will install the FuzzyOCR SA plugin designed to catch those nasty image-based spam messages.<br />
yum -y --enablerepo=smeupdates-testing install FuzzyOcr<br />
<br />
'''Server-Manager'''<br />
<br />
Using the Server-Manager Configuration/E-Mail panel, adjust the settings to these reasonable <br />
* Virus scanning Enabled<br />
* Spam filtering Enabled<br />
* Spam sensitivity Custom<br />
* Custom spam tagging level 4<br />
* Custom spam rejection level 12<br />
* Sort spam into junkmail folder Enabled<br />
* Modify subject of spam messages Enabled<br />
<br />
It is also recommend blocking all executable content. To do so, select (highlight) all of the attachment types other than zip files (the last two).<br />
<br />
Click Save.<br />
<br />
'''How It Works'''<br />
<br />
When receiving an incoming message, the server first tests for RBL and DNSBL listings, if enabled. If the sender is blacklisted, the messages are blocked outright and Spamassassin never sees it. <br />
<br />
With this configuration, the spammiest messages, those marked as 12 or above, will be rejected at the SMTP level. Those spam messages marked between 4 and 12, will be routed to the users' (IMAP) junkmail folder. This is done so the users can check for false-positives...valid messages that were classified as spam by SpamAssassin.<br />
<br />
Users may check their junkmail folders for false-positives via webmail, or, if they are using an IMAP mail client, by simply checking the junkmail folder exposed by their mail client.<br />
<br />
https://servername/webmail<br />
<br />
'''Tweaking'''<br />
<br />
The server will automatically delete old spam in the junkmail folders after 90 days. You can control the number of days old spam is kept with the following commands. Where 15 is the number of days you want to keep messages, do...<br />
<br />
db configuration setprop spamassassin MessageRetentionTime 15<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
then<br />
<br />
config show spamassassin<br />
<br />
If you think you are losing misclassified mail, adjust the ''Custom spam rejection level'' higher.<br />
<br />
If too much spam is making through to your inbox, carefully adjust the 'Custom spam tagging level' down. Many people use the level 4. Anything below that may result in false-positives. YMMV.<br />
<br />
If too much spam is building up in your (IMAP) junkmail folder, adjust the 'Custom spam rejection level' down or change the number of days spam is kept in the junkmail folder before being automatically deleted by the server.<br />
<br />
'''Bayesian (Learning) Filter'''<br />
<br />
Install the LearnAsSpam.pl, (optional) mailstats and sa-update scripts, then configure nightly cron jobs like this:<br />
<nowiki>cd /usr/bin<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.pl<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/spamfilter-stats-7.pl<br />
cd /etc/cron.d<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.cron<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/mailstats.cron<br />
cd /etc/cron.daily<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/sa-update<br />
chmod +x sa-update<br />
/etc/rc.d/init.d/crond restart</nowiki><br />
<br />
Using an IMAP mail client, create a new folder called 'LearnAsSpam' (case sensitive). It can be created at the top level (like 'Inbox') or as a sub-folder. Create the folder for each user that will help train the Bayesian filter. Webmail will work fine for creating this folder, as well as for checking the junkmail (filtered mail or quarantine) folder.<br />
<br />
If any spam messages make it past the filter and into your inbox, just move them into the LearnAsSpam folder. A nightly cron job will process them and delete them for you. This is how you train the Bayesian filter.<br />
<br />
'''Testing'''<br />
<br />
You can check the auto-learning statistics with this command. You will be able to note the accumulation of the spam tokens (or not). Note that the Bayesian filtering must receive 200 spam messages before it starts to function, so don't expect instantaneous results.<br />
sa-learn --dump magic<br />
<br />
You can check the spam filter log with this command: <br />
tail -50 /var/log/spamd/current | tai64nlocal<br />
<br />
If you ever see an error such as:<br />
''warn: bayes: cannot open bayes databases /etc/mail/spamassassin/bayes_* R/W: tie failed: Permission denied''<br />
Try adjusting some permissions with these commands:<br />
chown :spamd /var/spool/spamd/.spamassassin/*<br />
chmod g+rw /var/spool/spamd/.spamassassin/* <br />
<br />
'''Whitelist and Blacklist'''<br />
<br />
If mail comes in and it is misclassified as spam (and moved to the junkmail folder when that feature is enabled), you can add the sender to the whitelist so that future messages coming in from that sender are not filtered.<br />
<br />
Conversely, you can add a spammer to the blacklist so you never see their spam again. <br />
<br />
Add senders (or their entire domains) to the global whitelist (or blacklist) with commands similar to these (as root):<br />
db spamassassin setprop wbl.global *@vonage.com White<br />
db spamassassin setprop wbl.global *domain2.com White<br />
db spamassassin setprop wbl.global badname@baddomain.com Black<br />
db spamassassin setprop wbl.global *@verybaddomain.com Black<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it White<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can enter multiple addresses/domains for both white and black lists in one command<br />
db spamassassin setprop wbl.global name@domain.com White *domain2.com White *domain3.com Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can view the lists with this command:<br />
db spamassassin show<br />
<br />
You can delete one or more entries from the white/blacklist using<br />
db spamassassin delprop wbl.global name@domain.com *domain2.com<br />
* name@domain.com and *domain2.com must exactly match a value in the output from ''db spamassassin show'' to the ''left'' of the equals sign. <br />
* You do not need to specify ''White'' or ''Black'' when deleting entries.<br />
<br />
<br />
<br />
'''Clam Antivirus'''<br />
<br />
Update and check your Clam Antivirus with this command. This is normally done automatically every hour via cron.<br />
freshclam -v<br />
<br />
or<br />
freshclam --debug<br />
<br />
Verify hourly update checking by viewing the freshclam/current log file via the Server-Manager View Log Files panel.<br />
<br />
'''Realtime Blackhole Lists and DNS Blacklists'''<br />
<br />
To view the settings for the RBL and DNSBL, use this command:<br />
config show qpsmtpd<br />
<br />
If you followed the instructions above, both checks are enabled.<br />
<br />
To see the log of these tests, use a command like:<br />
tail /var/log/qpsmtpd/current | tai64nlocal <br />
<br />
To specify multiple RBLs, use a command like this:<br />
config setprop qpsmtpd RBLList \<br />
bl.spamcop.net,combined.njabl.org,dnsbl.ahbl.org,dnsbl-1.uceprotect.net,\<br />
list.dsbl.org,multihop.dsbl.org,psbl.surriel.com,zen.spamhaus.org<br />
<br />
Note: we have had trouble with the uceprotect.net level 2 list and sometimes remove it from the list as shown here.<br />
<br />
To enable or disable both available lists, use something like:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
<br />
To confirm any configuration changes and enact them:<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
'''More Information'''<br />
<br />
Introduction to Antispam Practices - [http://www.howtoforge.com/introduction_antispam_practices| here]<br />
<br />
Here is another great [http://mirror.contribs.org/smeserver//contribs/rmitchell/smeserver/howto/Spam%20blocking%20HOWTO%20using%20qpsmtpd%20&%20RBL%20for%20sme%20server.htm] howto.<br />
<br />
Informative URLs:<br />
* http://forums.contribs.org/index.php?topic=35178.0 <br />
* http://forums.contribs.org/index.php?topic=31278.0<br />
* http://forums.contribs.org/index.php?topic=31279.0<br />
* http://forums.contribs.org/index.php?topic=32158.0<br />
* http://mirror.contribs.org/smeserver/contribs/michaelw/sme7/<br />
* http://mirror.contribs.org/smeserver/contribs/bread/mailstats/<br />
* http://wiki.apache.org/spamassassin/BayesInSpamAssassin<br />
* Enter this command at a console:<br />
perldoc Mail::SpamAssassin::Conf <br />
Last Updated ( Thursday, 21 June 2007 )<br />
<br />
===Email Clients===<br />
===="concurrency limit reached" when using IMAP====<br />
Sometime shows as Thunderbird giving this error message,<br />
''This Mail-server is not a imap4 mail-server''<br />
<br />
To workaround thunderbirds limitations change, this thunderbird setting to false<br />
* Preferences, Advanced, Config editor (aka about:config): filter on tls.<br />
* set security.enable_tls to false<br />
<br />
You can also increase the ConcurrencyLimitPerIP and/or ConcurrencyLimit value for imap and/or imaps (secure)<br />
config setprop imap ConcurrencyLimitPerIP 20<br />
config setprop imaps ConcurrencyLimitPerIP 20<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
check<br />
config show imap<br />
tail -f /var/log/imap/current | tai64nlocal<br />
<br />
More detail can be found [http://forums.contribs.org/index.php?topic=33124.0 here].<br />
<br />
====Mail server is not an IMAP4 mail server====<br />
This is a bug in Thunderbird, the previous tips may help<br />
<br />
====The Bat====<br />
The gives this error message, but they are wrong.<br><br />
"This server uses TLS v3.0 which is considered to be obsolete and insecure. <br />
The server must use TLS v3.1 or above."<br />
<br />
<br />
====Outlook/Outlook Express give error 10060/0x800CCC90====<br />
Most likely OUTLOOK (EXPRESS) isn't configured correctly.<br />
<br />
-open OUTLOOK<br />
-click TOOLS > ACCOUNTS<br />
-click CHANGE (on the right-hand side)<br />
-find INCOMING MAIL SERVER & OUTGOING MAIL SERVER (on right-hand side)<br />
-type: mail.yourdomain.tld (in both places)<br />
-click MORE SETTINGS (on bottom-right)<br />
-click OUTGOING SERVER tab (at the top)<br />
-checkmark "MY OUTGOING SERVER REQUIRES AUTHENTICATION"<br />
-bullet "USE SAME SETTINGS AS INCOMING MAIL SERVER"<br />
-click ADVANCED tab (at the top)<br />
-find OUTGOING SERVER<br />
-checkmark "THIS SERVER REQUIRES A SECURE CONNECTION" (under outgoing server)<br />
-change 25 to 465<br />
-[possibly required, secure IMAP is 993]<br />
-click OK > NEXT > FINISHED<br />
-you're finished, your email should work now<br />
<br />
====Outlook test message doesn't come through====<br />
You clicked the TEST ACCOUNT SETTINGS in OUTLOOK didn't you? This is a bug in OUTLOOK. The test message sends a test email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. To test, send an actual message from OUTLOOK.<br />
<br />
If you want, you can try THUNDERBIRD. It's like OUTLOOK but made by a different company. It's completely free and works very well at home and at the office.<br />
<br />
====I can't receive/send email from my application (ACT!, vTiger, MS Outlook, etc)====<br />
Most likely, this is a bug the application you're using and not a problem with the SMESERVER. The application sends an email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. <br />
<br />
As a workaround you can disable the check for the 'Date header'.<br />
To disable this check on the internal interface:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
To disable this check for the external interface: <br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
====After I upgrade my SME Server, my email folders have disappeared when using IMAP====<br />
After upgrade, if there are missing IMAP folders, the client may need to re-subscribe to folders. This may affect either webmail users or users who use an IMAP email client.<br />
<br />
====Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4====<br />
The main problem here is that Microsoft has decided that Entourage will only support trusted, PEM Base-64 Encoded certificates. To use IMAPS or SMTPS from Entourage with your SME server, you will need to:<br />
1. Login to your Mac as a user with administrative privileges<br />
<br />
2. Open Safari and browse to https://''smeserver''/server-manager. <br />
When you receive the warning about your certificate:<br />
- click on "Show Certificate"<br />
- click and drag the gold-rimmed image of a certificate to your desktop. <br />
You will now have ''myserver.mydomain.tld.cer'' on your desktop.<br />
<br />
3. Locate and open the '''Microsoft Cert Manager'''<br />
- "Import" the certificate you downloaded in step 2.<br />
<br />
4. Highlight the imported certificate and "Export" it. <br />
- Select the "PEM..." format<br />
- add "''pem.''" to the beginning of the filename<br />
- export it to your Desktop<br />
<br />
5. Double-click on the new ''pem.myserver.mydomain.tld.cer'' <br />
- Apple's '''Keychain Access''' application will open.<br />
- Select the '''X509Anchors''' Keychain and click "OK"<br />
<br />
6. While still in Apple's '''Keychain Access''', select the "Certificates" category<br />
- Drag ''pem.myserver.mydomain.tld.cer'' into the certificates window.<br />
<br />
You should now be able to connect to your SME from your Entourage using IMAPS. <br />
<br />
If you are accessing your SME server using a different name than the one encoded in the certificate you will still receive a security warning from Entourage, but "OK" will now grant access to your folders.<br />
<br />
Notes: <br />
* Procedure mostly taken from http://www.kerio.com/manual/kmsug/en/ch09s06.html<br />
* I still get various other IMAP errors due, I suspect, to the "concurrency limit reached" issue.<br />
* Click on "Show Keychains" in Apple's "Keychain Access" if you need to delete a certificate and try again.<br />
<br />
====How do I get my e-mail to show the correct From Address====<br />
<br />
The From address on an e-mail is not supplied by the server. It is supplied by the e-mail client.<br />
<br />
* Configure your Account in your e-mail client with the correct FROM address.<br />
* You can change the FROM address in webmail with the following:<br />
**Login to webmail as the user, go to ''options-personal information'' and change the ''identity'' to have the correct FROM address. You can have multiple identities with a single user.<br />
<br />
===Server Settings===<br />
====Double bounce messages====<br />
To stop admin receiving double bounce messages<br />
<br />
config setprop qmail DoubleBounceTo someoneuser<br />
signal-event email-update<br />
<br />
Or just delete them. You risk losing legitimate double bounces (which are<br />
rare, but you want to look at them when they do occur)<br />
<br />
config setprop qmail DoubleBounceTo devnull<br />
signal-event email-update<br />
<br />
see a longer explaination [[Email_delete_double-bounce_messages | here]]<br />
<br />
====Keep a copy of all emails====<br />
You may need to keep a copy of all emails sent to or from your email server.<br />
This may be for legal, or other reasons.<br />
<br />
The following instructions will create a new user account (maillog) and forward every email that goes through your SME server to it.<br />
<br />
First, log onto the server-manager and create the user '''maillog'''<br />
<br />
Go to the SME Command Line (logon as root) and issue the following commands:<br />
<br />
config setprop qpsmtpd Bcc enabled<br />
signal-event email-update<br />
<br />
Optionally make the forwarding of the emails invisible to the end user. Without it, there will be an X-Copied-To: header in each email. Run this command before the signal-event<br />
<br />
config setprop qpsmtpd BccMode bcc<br />
<br />
If you want to view the emails, point your email client at the SME and log on as maillog.<br />
<br />
====Set max email size====<br />
There are several components involved in sending email on a SME server. Each component has a size limit that may affect an email message that passes through the server.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
! Subsystem<br />
! Function<br />
! Default Limit<br />
! Command to change size<br />
! Notes<br />
|-<br />
|qmail<br />
|Delivers email to local mailboxes and to remote servers<br />
|15000000<br />
|config&nbsp;setprop&nbsp;qmail&nbsp;MaxMessageSize&nbsp;xx000000<br />
|Value is in BYTES. 15000000 equals approximately 15MB<br />
|-<br />
|clamav<br />
|Used to scan emails and attachments<br />
|15M<br />
|config&nbsp;setprop&nbsp;clamav&nbsp;MaxFileSize&nbsp;15M<br />
|value includes human-readable abbreviations. "15M" equlas 15 MegaBytes.<br />
|-<br />
|qpsmtpd<br />
|The clamav plugin to qpsmtpd is called with a specified size limit.<br />
|25000000<br />
|config&nbsp;setprop&nbsp;qpsmtpd&nbsp;MaxScannerSize&nbsp;xx000000<br />
|Value is in BYTES.<br>Question: does this value override the setting of 'MaxFileSize', or will the smaller value prevail?<br />
|-<br />
|php<br />
|The php maximum file upload size will determine the largest file you can attach to an email message using horde (or any other php email client)<br />
|10M<br />
|config&nbsp;setprop&nbsp;php&nbsp;UploadMaxFilesize&nbsp;10M<br />
|<br />
|-<br />
|}<br />
A note about clamav:<br><br />
ClamAV includes settings to prevent the scanning of archives that could cause problems if fully expanded; if an attachment cannot be scanned, it will be rejected.<br />
<br />
These attributes could result in the rejection of a compressed attachment on a SME server:<br />
* ArchiveMaxCompressionRatio (default 300)<br />
* MaxFiles (default 1500)<br />
* MaxRecursion (default 8)<br />
<br />
====Add the admin user as an administrator for Horde====<br />
<br />
config setprop horde Administration enabled <br />
signal-event email-update<br />
<br />
==== Large attachments not displaying in webmail ====<br />
Due to limits set in the PHP configuration it might be that webmail will not display large attachments (see also [[bugzilla:3990]]). The following entries are related to the error and can be found in the log files:<br />
<br />
'''/var/log/messages'''<br />
Mar 13 00:00:12 box1 httpd: PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 154 bytes) in /home/httpd/html/horde/imp/lib/MIME/Contents.php on line 173<br />
<br />
'''/var/log/httpd/error_log'''<br />
Allowed memory size of 33554432 bytes exhausted (tried to allocate 0 bytes)<br />
<br />
The default MemoryLimit setting in PHP is set to 32M the value can be changed using the commands below replacing ''XX'' with the value you desire.<br />
{{Note box|You can set the MemoryLimit any value you like but be sure to add the capital M as a suffix for Megabytes.}}<br />
db configuration setprop php MemoryLimit XXM<br />
expand-template /etc/php.ini<br />
sv t httpd-e-smith<br />
<br />
====Disable mail to a user from an external network====<br />
Can be either a user, pseudonym or group<br />
db accounts setprop groupname/username Visible internal<br />
signal-event email-update<br />
<br />
====I can't receive mail at: user@mail.domain.tld====<br />
Add mail.domain.tld as a virtualdomain.<br />
-login to SERVER-MANAGER<br />
-click DOMAINS (on the left)<br />
-click ADD<br />
-type: mail.domain.tld<br />
<br />
====How do I find out who is logged into webmail and what IP number.====<br />
This is logged is in /var/log/messages.<br />
<br />
====How do I enable smtp authentication for users on the internal network.====<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cp /etc/e-smith/templates/var/service/qpsmtpd/config/peers/0/05auth_cvm_unix_local .<br />
signal-event email-update<br />
(note the "." at the end of the 3rd line)<br><br />
Authentication for the local network will now follow the setting of config::qpsmtpd::Authentication<br />
<br />
====How do I disable SMTP relay for unauthenticated LAN clients====<br />
http://forums.contribs.org/index.php?topic=38797.msg176490#msg176490<br />
* Enable smtp authentication as shown above<br />
* Disable un-authenticated smtp relay for the local network(s)using:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients<br />
echo "# SMTP Relay from local network denied by custom template" >\<br />
/etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients/80relayFromLocalNetwork<br />
signal-event email-update<br />
<br />
* Configure your email clients to use smtps with authentication:<br><br />
- change outgoing smtp port to 465 and select SSL<br><br />
- enable Authentication against the outgoing mail server<br />
<br />
<br />
====Internet provider's port 25 is blocked: How to set an alternative port for the SMTP server====<br />
If your provider is blocking smtp port 25 on your internet connection but your hosting provider is offering an alternative port (or when using some relay service) you can simply set this alternative port by adding it to the 'Address of Internet provider's mail server' value in the 'E-mail delivery settings' screen of the server-manager like this:<br />
<internet providers mail server name or ip-address>:<alternative port><br />
For example: mail.mydomain.com:587<br />
<br />
====How do I enable and configure a disclaimer in email messages====<br />
<br />
<br />
A disclaimer message can be added to the footer of all outgoing email messages.<br />
<br />
The message can be the same for all domains or it can be different for all domains.<br />
<br />
This functionality is part of sme7.2 release so make sure you have upgraded before doing this.<br />
<br />
To create a general disclaimer for all domains on your sme server<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer<br />
Enter the required disclaimer text <br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
To make the changes take effect<br />
signal-event email-update<br />
<br />
<br />
To create domain specific disclaimers, create seperate domain based disclaimer text files<br />
<br />
Delete the general (all domains) disclaimer file if you have already created it<br />
rm /service/qpsmtpd/config/disclaimer<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer_domain1.com.au<br />
pico -w /service/qpsmtpd/config/disclaimer_domain2.com<br />
pico -w /service/qpsmtpd/config/disclaimer_domain3.org<br />
<br />
Enter the required text in each disclaimer file<br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
After making any changes remember to do<br />
signal-event email-update<br />
<br />
<br />
Note if you only wish to have a disclaimer for some domains, then only create a disclaimer text file for those domains <br />
<br />
<br />
Note also the criteria for when a disclaimer is attached <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648)<br />
<br />
eg a disclaimer is added to internal to external messages but not internal to internal messages.<br />
<br />
There are also various switches that can be applied <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648).<br />
<br />
<br />
To disable the disclaimer function for all domains on your sme server<br />
config setprop smtpd disclaimer disabled<br />
signal-event email-update<br />
<br />
<br />
====Email WBL server manager panel====<br />
<br />
There is a server manager contrib to allow GUI control of email white and black lists.<br />
<br />
The panel allows easy configuration of functionality that is built into qmail, qpsmtpd and spamassassin. For more information google for qmail & qpsmtpd, read the spamassassin section in this wiki article and see [http://wiki.contribs.org/Email#Default_Plugin_Configuration default qpsmtpd plugin confguration]).<br />
<br />
{{Warning box|It is a test release, although it has been in use since Jan 2007 and appears functionaly stable. To install do:<br />
wget http://mirror.contribs.org/smeserver/contribs/dmay/smeserver/7.x/testing/smeserver-wbl/smeserver-wbl-0.0.1-a8.dmay.noarch.rpm <br />
rpm -Uvh smeserver-wbl*.rpm<br />
}}<br />
<br />
There are two main sections, Reject and Accept, where you can control settings.<br />
<br />
Reject - Black lists are used for rejecting e-mail traffic<br />
<br />
DNSBL status - DNSBL is an abbreviation for "DNS blacklist". <br />
It is a list of IP addresses known to be spammers.<br />
RHSBL status - RHSBL is an abbreviation for "Right Hand Side Blacklist". <br />
It is a list of domain names known to be spammers.<br />
qpsmtpd badhelo - Check a HELO message delivered from a connecting host. <br />
Reject any that appear in badhelo during the 'helo' stage.<br />
qmail badmailfrom - Check envelope sender addresses. <br />
Reject any that appear (@host or user@host) in badmailfrom during the 'mail' <br />
stage.<br />
<br />
Accept - White lists are used for accepting e-mail traffic<br />
<br />
Whitelists status - White Lists: ACCEPT<br />
qpsmtpd whitelisthosts - Any IP address listed in whitelisthosts will be exempted <br />
from any further validation during the 'connect' stage.<br />
qpsmtpd whitelisthelo - Any host that issues a HELO matching an entry in whitelisthelo <br />
will be exempted from further validation during the 'helo' stage.<br />
qpsmtpd whitelistsenders - Any envelope sender of a mail (@host or user@host) matching an <br />
entry in whitelistsenders will be exempted from further validation<br />
during the 'mail' stage.<br />
spamassassin whitelist_from - Any envelope sender of a mail (*@host or user@host) matching an <br />
entry in whitelist_from will be exempted from spamassassin rejection.<br />
<br />
<br />
After making any changes using this panel you must click both the Save and Update buttons, in order for changes to take effect.<br />
<br />
===External Access===<br />
====Allow external IMAP mail access====<br />
There was a deliberate decision to remove non-SSL protected username/password<br />
services from the external interface.<br />
<br />
to allow unsecure IMAP access<br />
<br />
config setprop imap access public<br />
signal-event email-update<br />
<br />
But before you do this try to use secure IMAP<br><br />
fixme: explain how<br />
<br />
====POP3 & webmail HTTP====<br />
I want to set my SMESERVER to allow POP3 (or webmail HTTP) but it's not an option, I only see POP3S (or webmail HTTPS).<br />
<br />
The SMESERVER is secure by design. POP3 (or webmail HTTP) is viewed as inadequate security and removed as an option from a standard installation to encourage unknowing administrators to select the 'best practice' option -a secure connection with POP3S, IMAPS, or HTTPS.<br />
<br />
You can still set your SMESERVER to allow POP3 settings by:<br />
config setprop pop3 access public<br />
signal-event email-update<br />
<br />
====Allow external pop3 access====<br />
<br />
Email settings > POP3 server access in SME 7.1 server-manager allows only pop3s protocol for clients outside the LAN. Some email clients (eg The Bat! v3.98.4) won't allow pop3s connections to SME 7.1 because of ssl version conflict. Until this is sorted out, a workaround is to hack SME to allow regular pop3 on the external interface using the following commands. <br />
<br />
config setprop pop3 access public<br />
signal-event email-update<br />
svc -t /service/pop3s <br />
<br />
more information [[bugzilla:2620]]<br />
<br />
===Imap===<br />
====Folders with a dot in name====<br />
Email folder names that have a period ('.') in the folder name, will be split into sub-folders.<br />
e.g. folder name 'www.contribs.org' is created as<br />
www<br />
contribs<br />
org<br />
<br />
===qpsmtpd===<br />
SME uses the [http://smtpd.develooper.com qpsmtpd] smtp daemon.<br />
<br />
====Official Description====<br />
qpsmtpd is a flexible smtpd daemon written in Perl. Apart from the core SMTP features, all functionality is implemented in small "extension plugins" using the easy to use object oriented plugin API.<br />
<br />
qpsmtpd was originally written as a drop-in qmail-smtpd replacement, but now it also includes smtp forward, postfix, exim and maildir "backends".<br />
<br />
qpsmtpd wiki: http://wiki.qpsmtpd.org <br />
<br />
<br />
====Default Plugin Configuration====<br />
SME uses the following [http://wiki.qpsmtpd.org/plugins qpsmtpd plugins] to evaluate each incoming email. <br />
<br />
SME maintains 2 distinct configurations: one for the 'local' networks (as defined in server-manager::Security::Local networks) and another for 'remote' networks (everyone else).<br />
<br />
The default configuration of each plugin is indicated in the 'Default Status' column.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
!Plugin<br />
!Purpose<br />
!Default Status<br />
|-<br />
|hosts_allow<br />
|Prohibit more than "InstancesPerIP" connections from any single host (change with 'config setprop smtp InstancesPerIP'). Allow or deny connections according to the contents of /var/service/qpsmtpd/config/hosts_allow. See [http://svn.perl.org/qpsmtpd/trunk/plugins/hosts_allow hosts_allow SVN code] for more details.<br />
|[http://bugs.contribs.org/show_bug.cgi?id=3352 upcoming]<br />
|-<br />
|peers<br />
|Allow different plugin configuration based on the sending computer's IP address. By default SME maintains different configurations for the local networks (in /var/service/qpsmtpd/config/peers/local) and for everyone else (in /var/service/qpsmtpd/config/peers/0)<br />
|enabled<br />
|-<br />
|logging/logterse<br />
|Allow greater logging detail using smaller log files<br />
|enabled<br />
|-<br />
|auth/auth_cvm_unix_local<br />
|Allow authenticated smtp relay<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_earlytalker<br />
|reject email from servers that talk out of turn<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|count_unrecognized_commands<br />
|reject email from servers that issue ''X'' invalid commands<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|bcc<br />
|bcc all email to a specific address for archiving<br />
|'''disabled'''<br />
|-<br />
|check_relay<br />
|Check to see if relaying is allowed (in case the recipient is not listed in one of SME's local domains)<br />
|enabled<br />
|-<br />
|check_norelay<br />
|Check to see if the sending server is specifically forbidden to relay through us.<br />
|enabled<br />
|-<br />
|require_resolvable_fromhost<br />
|Check that the domain listed in the sender's email address is resolvable<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_basicheaders<br />
|reject email that lacks either a From: or Date: header<br />
|enabled<br />
|-<br />
|rhsbl<br />
|Reject email if the sender's email domain has a reputation for disregarding smtp RFCs.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|dnsbl<br />
|Reject email from hosts listed in your configured dnsbl servers<br />
|'''disabled'''<br />
|-<br />
|check_badmailfrom<br />
|Reject email where the sender address is listed in /var/service/qpsmtpd/config/badmailfrom<br />
|enabled<br />
|-<br />
|check_badrcptto_patterns<br />
|Reject email addressed to any address matching an expression listed in /var/service/qpsmtpd/config/badrcptto_patterns<br />
|enabled<br />
|-<br />
|check_badrcptto<br />
|Reject email addressed to any address listed in /var/service/qpsmtpd/config/badrcptto<br />
|enabled<br />
|-<br />
|check_spamhelo<br />
|Reject email from hosts that say 'helo ...' using a value in /var/service/qpsmtpd/config/badhelo<br />
|enabled<br />
|-<br />
|check_smtp_forward<br />
|If ''config show DelegateMailServer'' or ''db domains show <domainname> MailServer'' is set (telling SME to deliver email for all domains or just <domainname> to another server), check_smtp_forward will connect to the specified server and will reject the message outright if the internal mail server would also reject it.<br />
|'''disabled'''<br>unless an internal mail server is configured.<br />
|-<br />
|check_goodrcptto<br />
|Accept email only if the recipient address matches an entry in /var/service/qpsmtpd/config/goodrcptto. For domains that are configured to use an internal mail server, the entire domain name will be added to .../goodrcptto.<br />
|enabled<br />
|-<br />
|rcpt_ok<br />
|Return 'OK' if none of the other host checks has returned 'DENY' (??)<br />
|enabled<br />
|-<br />
|pattern_filter<br />
|Reject email according to content patterns (??)<br />
|'''disabled'''<br />
|-<br />
|tnef2mime<br />
|Convert MS TNEF (winmail.dat) and uuencoded attachments to MIME<br />
|enabled<br />
|-<br />
|disclaimer<br />
|Add a configurable disclaimer to email messages<br />
|'''disabled'''<br />
|-<br />
|spamassassin<br />
|Check email using spamassassin, and optionally reject it completely if the score exceeds a configurable value.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|virus/clamav <br />
|Scan incoming email with ClamAV<br />
|enabled<br />
|-<br />
|queue/qmail-queue<br />
|Deliver the incoming message to qmail for delivery.<br />
|enabled<br />
|-<br />
|}<br />
<br />
===Internal Mail Servers===<br />
SME can be configured as a spam and antivirus filter for one or more "Internal" mail servers on a domain-by-domain basis. The mail server specified does not have to be on the same local network as your SME server.<br />
<br />
====Deliver ALL email to a single internal mail server====<br />
You can deliver all email for all domains on your SME server to a single internal mail server by setting the mail server address in server-manager::Configuration::E-mail::Change e-mail delivery settings::Address of internal mail server.<br />
<br />
====Deliver email for one domain to an internal mail server====<br />
You can also configure only a single domain to use an internal mail server, or you can configure different domains to use different internal mail servers.<br />
<br />
First, create the necessary virtual domains using server-manager::Configuration::Domains::Add Domain.<br />
<br />
Then, (assuming your domain is called ''test.com'' and the actual mail server is at ''a.b.c.d'' issue the following commands:<br />
db domains setprop test.com MailServer a.b.c.d<br />
signal-event email-update<br />
<br />
=== Secondary/Backup Mail Server Considerations ===<br />
<br />
Many people misunderstand the issues of using a secondary or backup <br />
mail server (backup MX) to hold your mail before it gets delivered <br />
to your SME Server. If you consider putting a backup mail server in <br />
place because you are concerned about lost mail because your internet<br />
connection may occasionally drop out, think again and consider the issues<br />
discussed below.<br />
<br />
====What is ''Backup MX''====<br />
<br />
A backup MX is a system whereby through your DNS records you tell other<br />
servers on the internet that in order to deliver mail to your domain they<br />
first need to try the primary MX record and if they fail to connect they<br />
can try to connect to one or more of your listed backup or secondary mail <br />
servers. See also http://en.wikipedia.org/wiki/MX_record<br />
<br />
====The process of delivering email to your SME Server====<br />
<br />
So lets look at how mail gets delivered without and with a <br />
''backup mx'' when your Internet link, ISP or server is down.<br />
<br />
====='''Without''' a backup MX=====<br />
<br />
* The sending mail server cannot connect to your server.<br />
* The sending mail server MUST queue the mail and try again later.<br />
* The mail stays on the sender's server.<br />
* The sender's server resends the mail at a later date.<br />
<br />
''The requirement to re-queue is a fundamental part of the SMTP protocol - <br />
it is not optional. So, if your server is '''offline''' due to a link or ISP <br />
outage, '''the mail just stays at the sender's server until you are once <br />
again reachable'''.<br />
<br />
====='''With''' a backup MX=====<br />
<br />
* The sending mail server cannot contact your server.<br />
* The sending mail server sends the mail to your secondary MX.<br />
* The secondary MX queues the mail until your link/server is up.<br />
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'').<br />
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs.<br />
* You have no, or little, visibility over the queued mail.<br />
* When your link comes up, the secondary MX sends the mail on to your server.<br />
* You have added more hops, more systems and more delay to the process.<br />
<br />
If you think that a backup MX will protect against broken mail servers <br />
which don't re-queue, you can't. Those servers will drop mail on the floor<br />
at random times, for example when ''their'' Internet link is down. <br />
<br />
Those servers are also highly likely to never try your backup MX. <br />
<br />
Thankfully those servers are mostly gone from the Internet, but adding a <br />
secondary MX doesn't really improve the chances that they won't drop mail<br />
destined for your server on the floor.<br />
<br />
====Backup MX and SPAM Filtering====<br />
<br />
On top of the issue, indicated above, there is another issue to consider<br />
and that is what happens with SPAM due to the use of a ''Backup MX''. <br />
<br />
Your SME Server takes care of filtering a lot of SPAM by checking on the full <br />
username & domain at the time it is received.<br />
<br />
For example if your server hosts '''example.com''' and someone sends <br />
mail to '''joeuser@example.com''', the server will '''only''' accept the mail<br />
if joeuser is a local user/alias/group/pseudonym on the server. <br />
Otherwise, the mail is rejected during the SMTP transaction.<br />
<br />
A backup mail server however, generally does not have a full list of<br />
users against which it can check if it should accept the mail for the given<br />
domain. Hence it will accept mail for ''invalid'' users.<br />
<br />
So:<br />
<br />
* If you trust the secondary MX, you <u>will</u> accept a lot of SPAM when the link comes up.<br />
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.<br />
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.<br />
<br />
The SPAM backscatter can only be stopped if the secondary MX has a full list<br />
of users for your domain to allow filtering to occur.<br />
<br />
But:<br />
<br />
* You need to be able to configure this secondary MX with such user/domain lists<br />
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration<br />
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.<br />
<br />
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find <br />
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail. <br />
<br />
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.<br />
<br />
* If you bounce mail at your server, you have logs to show what's wrong. <br />
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.<br />
<br />
==== Summary ====<br />
<br />
In summary, if your server/Internet connection is available most (let's say >90%) of <br />
the time, you are generally better off <u>without a secondary MX</u>. <br />
<br />
If your server/link is down more than this (e.g. dialup), you should not be delivering mail <br />
directly to your server.<br />
<br />
If you still want to consider setting up a seconday MX, ensure that:<br />
<br />
* you have fully control of the configuration of each of the email gateways for your domain<br />
* each gateway can make decisions on whether to accept/reject mail for the users at the domain<br />
<br />
===User accounts===<br />
====Multiple users with the same name on different domains====<br />
''The Manual contains a detailed explanation here [http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter9#Pseudonyms], however, this question is frequently asked in the forums and this FAQ was added in response to this thread [http://forums.contribs.org/index.php?topic=41558.0;all]''<br />
<br />
SME only supports one name set, so you cannot have multiple user accounts for the same user (eg joe) at different domains, you can only have one user account for joe which applies to all domains.<br />
<br />
The workaround is to create user accounts with a different name to what will be used as an email address.<br />
<br />
eg.<br />
*create user account joe1<br />
*create user account joe2<br />
*create user account joe3<br />
<br />
'''DO NOT create a user account for joe'''<br />
<br />
*create pseudonym for joe@domain1 which forwards to user account joe1<br />
*create pseudonym for joe@domain2 which forwards to user account joe2<br />
*create pseudonym for joe@domain3 which forwards to user account joe3<br />
<br />
joe1 logs in using joe1 but advertises their email address as joe@domain1<br />
<br />
Your main or primary domain is created during initial setup in the admin console, Configure this server. <br />
Your additional domains are created using the Domains panel, and are called Virtual domains, but they function virtually identically to the main domain. In the Domains panel, you select an ibay for the content that will apply to virtual domain web sites.<br />
<br />
<br />
The mail server accepts mail for all valid domains (either the main or virtual), and delivers the mail to end user acounts or pseudonym addresses.<br />
<br />
Note, you do not need to use pseudonyms.<br />
<br />
You can just do the following.<br />
*create user account joe1 with effective email address of joe1@domain1<br />
*create user account joe2 with effective email address of joe2@domain2<br />
*create user account joe3 with effective email address of joe3@domain3<br />
<br />
This arrangement will work fine, but note that if email is inadvertantly sent to joe2@domain1 then joe2 will still receive that email (rather than joe1).<br />
External users would not really be sending to joe2@domain1 as that address has never been advised to anyone as being active.<br />
<br />
<noinclude>[[Category:Howto]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=Email&diff=10261
Email
2008-07-17T15:32:34Z
<p>Mercyh: /* Multiple users with the same name on different domains */</p>
<hr />
<div>==Email==<br />
===Spam===<br />
====Spamassassin====<br />
Set spamassassin for automatically delete junkmail.<br />
You can change the "days" that spamassassin sets to automatically delete junkmail, to delete after two months <br />
<br />
db configuration setprop spamassassin MessageRetentionTime 60 <br />
signal-event email-update <br />
<br />
<br />
The "Custom spam rejection level" will only work when "Spam sensitivity" is set to custom.<br />
<ol></li><li>Open server-manager.<br />
</li><li>Click e-mail in the navigation pane (left-hand side).<br />
</li><li>Click Change e-mail filtering settings.<br />
</li><li>Change "Spam sensitivity" to custom and adjust the settings to your liking.<br />
</li></ol><br />
<br />
This happens because by default, no mail (except for viruses) gets rejected without the admin doing something first.<br />
<br />
====='''X-Spam-Level Header in Email Messages'''=====<br />
SME does not create an X-Spam-Level header in processed email messages by default.<br />
<br />
To enable this capability:<br />
/usr/bin/yum install --enablerepo=smecontribs smeserver-qpsmtpd-spamassassinlevelstars<br />
signal-event email-update<br />
<br />
(Based on [[Bugzilla:3505]])<br />
<br />
=====Custom Rule Scores=====<br />
You can customize the score assigned by a specific Spamassassin rule (SARE_ADULT2 in this case) as follows:<br />
mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
echo "score SARE_ADULT2 20.000" >> 20localscores<br />
signal-event email-update<br />
<br />
You can now add additional tests and custom scores by editing the newly-created template fragment ''20localscores'' and adding new custom scores using:<br />
pico -w /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
Each custom score goes on its own line. If you enter a score surrounded by parentheses, the "custom" score will be added to the default score for the specified test (use ''score TEST_NAME (-1)'' to reduce the score for 'TEST_NAME' by 1) <br />
<br />
You can remove these customizations using: <br />
rm -f /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
<br />
References:<br />
* http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#scoring_options<br />
* http://spamassassin.apache.org/tests_3_2_x.html<br />
* http://www.rulesemporium.com/<br />
<br />
====Real-time Blackhole List (RBL)====<br />
Enabling RBL's <br><br />
RBL's are disabled by default to allow maximum accommodation (your ISP may be on a RBL & you may not know it). You can enable RBL's by:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
signal-event email-update<br />
<br />
You can see your RBL's by:<br />
config show qpsmtpd<br />
<br />
You can add to your RBL's by:<br />
config setprop qpsmtpd RBLList <rbl-list-name><br />
signal-event email-update<br />
<br />
Many will argue what's best but most would agree that you can set best-practice recommended settings by:<br />
config setprop qpsmtpd RBLList zen.spamhaus.org:whois.rfc-ignorant.org:dnsbl.njabl.org<br />
signal-event email-update<br />
<br />
Note: More information on this topic can be found here:<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#RHSBL_Servers]<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#DNSBL_Servers]<br />
<br />
====Server Only====<br />
Some of the spam filter rules cannot work unless the SMESERVER knows the external IP of the box. If you put a SMESERVER in server-only mode behind other firewalls, it will lose some of the anti-spam rules. For example, the rule that blocks attempts where spammers try "HELO a.b.c.d" where a.b.c.d is your external IP address.<br />
<br />
Unfortunately, many admins believe that port-forwarding SMTP provides additional security. It doesn't, it limits the SMESERVER's ability to apply some rules.<br />
<br />
<br />
====I want to enable GreyListing====<br />
GreyListing support is under the covers and can easily be enabled for those who know what they are doing. However, many experienced users found that they spent more time looking after the greylisting configuration than they received in benefit.<br />
<br />
====Setup Blacklists & Bayesian Autolearning====<br />
<br />
(Much of what follows has been shamelessly copied from the Sonoracomm howto)<br />
<br />
The default SME settings (as you can see [http://wiki.contribs.org/Email#Default_Plugin_Configuration here]) do not include DNSBL filtering, spam rejection, or (which is not obvious from the above) bayesian filtering in spamassassin to allow spamassassin to learn from received email and improve over time.<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set<br />
thresholds for the bayesian filter.<br />
<br />
config setprop spamassassin UseBayes 1<br />
config setprop spamassassin BayesAutoLearnThresholdSpam 4.00<br />
config setprop spamassassin BayesAutoLearnThresholdNonspam 0.10<br />
expand-template /etc/mail/spamassassin/local.cf<br />
sa-learn --sync --dbpath /var/spool/spamd/.spamassassin -u spamd<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes_*<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes.mutex<br />
chmod 640 /var/spool/spamd/.spamassassin/bayes_* <br />
config setprop qpsmtpd DNSBL enabled<br />
config setprop qpsmtpd RHSBL enabled<br />
config setprop spamassassin status enabled<br />
config setprop spamassassin RejectLevel 12<br />
config setprop spamassassin TagLevel 4<br />
config setprop spamassassin Sensitivity custom<br />
signal-event email-update<br />
<br />
These commands will:<br />
* enable spamassassin<br />
* configure spamassassin to reject any email with a score above 12<br />
* tag spam scored between 4 and 12 in the email header<br />
* enable bayesian filter<br />
* 'autolearn' as SPAM any email with a score above 4.00<br />
* 'autolearn' as HAM any email with a score below 0.10<br />
* enable RHSBL using the default SBLList. Note that rhsbl checking has been known to place a heavy burden on SME servers.<br />
* enable DNSBL using the default RBLList<br />
<br />
====The entire Sonoracomm howto from Google's text cache====<br />
* The Sonoracomm HowTo has been a very well regarded set of instructions for SME mail server configuration for quite a while.<br />
<br />
* This section was created during an extended outage of the Sonoracomm web server (in 2007?)<br />
<br />
* The Sonoracomm HowTo has been updated since this section was created, and is well worth examining. View the current version at: http://www.sonoracomm.com/index.php?option=com_content&task=view&id=49&Itemid=32<br />
<br />
* The content below has been modified to include changes suggested in the bug tracker and forums.<br />
<br />
* These instructions are aimed mostly at configuring SME as the only mail server, not for using SME with an internal mail server. (Specifically, LearnAsSpam.pl is harder to configure when using an internal mail server - you would have to develop a method for getting the unmarked SPAM into an IMAP folder directly on the SME server itself. Not impossible, but difficult!)<br />
<br />
'''SONORA COMMUNICATIONS, INC.'''<br />
<br />
This is a quick configuration howto, not an in-depth look at SpamAssassin. Much more can be done<br />
beyond this document, but this will take a big dent out of your spam and free up CPU cycles on your server.<br />
<br />
See 'More Information' at the end.<br />
<br />
'''SpamAssassin'''<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set thresholds for the bayesian filter.<br />
<nowiki>rpm -Uvh \<br />
http://mirror.contribs.org/smeserver/contribs/\<br />
michaelw/sme7/smeserver-spamassassin-features-0.0.2-0.noarch.rpm</nowiki><br />
<br />
This command will install the FuzzyOCR SA plugin designed to catch those nasty image-based spam messages.<br />
yum -y --enablerepo=smeupdates-testing install FuzzyOcr<br />
<br />
'''Server-Manager'''<br />
<br />
Using the Server-Manager Configuration/E-Mail panel, adjust the settings to these reasonable <br />
* Virus scanning Enabled<br />
* Spam filtering Enabled<br />
* Spam sensitivity Custom<br />
* Custom spam tagging level 4<br />
* Custom spam rejection level 12<br />
* Sort spam into junkmail folder Enabled<br />
* Modify subject of spam messages Enabled<br />
<br />
It is also recommend blocking all executable content. To do so, select (highlight) all of the attachment types other than zip files (the last two).<br />
<br />
Click Save.<br />
<br />
'''How It Works'''<br />
<br />
When receiving an incoming message, the server first tests for RBL and DNSBL listings, if enabled. If the sender is blacklisted, the messages are blocked outright and Spamassassin never sees it. <br />
<br />
With this configuration, the spammiest messages, those marked as 12 or above, will be rejected at the SMTP level. Those spam messages marked between 4 and 12, will be routed to the users' (IMAP) junkmail folder. This is done so the users can check for false-positives...valid messages that were classified as spam by SpamAssassin.<br />
<br />
Users may check their junkmail folders for false-positives via webmail, or, if they are using an IMAP mail client, by simply checking the junkmail folder exposed by their mail client.<br />
<br />
https://servername/webmail<br />
<br />
'''Tweaking'''<br />
<br />
The server will automatically delete old spam in the junkmail folders after 90 days. You can control the number of days old spam is kept with the following commands. Where 15 is the number of days you want to keep messages, do...<br />
<br />
db configuration setprop spamassassin MessageRetentionTime 15<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
then<br />
<br />
config show spamassassin<br />
<br />
If you think you are losing misclassified mail, adjust the ''Custom spam rejection level'' higher.<br />
<br />
If too much spam is making through to your inbox, carefully adjust the 'Custom spam tagging level' down. Many people use the level 4. Anything below that may result in false-positives. YMMV.<br />
<br />
If too much spam is building up in your (IMAP) junkmail folder, adjust the 'Custom spam rejection level' down or change the number of days spam is kept in the junkmail folder before being automatically deleted by the server.<br />
<br />
'''Bayesian (Learning) Filter'''<br />
<br />
Install the LearnAsSpam.pl, (optional) mailstats and sa-update scripts, then configure nightly cron jobs like this:<br />
<nowiki>cd /usr/bin<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.pl<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/spamfilter-stats-7.pl<br />
cd /etc/cron.d<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.cron<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/mailstats.cron<br />
cd /etc/cron.daily<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/sa-update<br />
chmod +x sa-update<br />
/etc/rc.d/init.d/crond restart</nowiki><br />
<br />
Using an IMAP mail client, create a new folder called 'LearnAsSpam' (case sensitive). It can be created at the top level (like 'Inbox') or as a sub-folder. Create the folder for each user that will help train the Bayesian filter. Webmail will work fine for creating this folder, as well as for checking the junkmail (filtered mail or quarantine) folder.<br />
<br />
If any spam messages make it past the filter and into your inbox, just move them into the LearnAsSpam folder. A nightly cron job will process them and delete them for you. This is how you train the Bayesian filter.<br />
<br />
'''Testing'''<br />
<br />
You can check the auto-learning statistics with this command. You will be able to note the accumulation of the spam tokens (or not). Note that the Bayesian filtering must receive 200 spam messages before it starts to function, so don't expect instantaneous results.<br />
sa-learn --dump magic<br />
<br />
You can check the spam filter log with this command: <br />
tail -50 /var/log/spamd/current | tai64nlocal<br />
<br />
If you ever see an error such as:<br />
''warn: bayes: cannot open bayes databases /etc/mail/spamassassin/bayes_* R/W: tie failed: Permission denied''<br />
Try adjusting some permissions with these commands:<br />
chown :spamd /var/spool/spamd/.spamassassin/*<br />
chmod g+rw /var/spool/spamd/.spamassassin/* <br />
<br />
'''Whitelist and Blacklist'''<br />
<br />
If mail comes in and it is misclassified as spam (and moved to the junkmail folder when that feature is enabled), you can add the sender to the whitelist so that future messages coming in from that sender are not filtered.<br />
<br />
Conversely, you can add a spammer to the blacklist so you never see their spam again. <br />
<br />
Add senders (or their entire domains) to the global whitelist (or blacklist) with commands similar to these (as root):<br />
db spamassassin setprop wbl.global *@vonage.com White<br />
db spamassassin setprop wbl.global *domain2.com White<br />
db spamassassin setprop wbl.global badname@baddomain.com Black<br />
db spamassassin setprop wbl.global *@verybaddomain.com Black<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it White<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can enter multiple addresses/domains for both white and black lists in one command<br />
db spamassassin setprop wbl.global name@domain.com White *domain2.com White *domain3.com Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can view the lists with this command:<br />
db spamassassin show<br />
<br />
You can delete one or more entries from the white/blacklist using<br />
db spamassassin delprop wbl.global name@domain.com *domain2.com<br />
* name@domain.com and *domain2.com must exactly match a value in the output from ''db spamassassin show'' to the ''left'' of the equals sign. <br />
* You do not need to specify ''White'' or ''Black'' when deleting entries.<br />
<br />
<br />
<br />
'''Clam Antivirus'''<br />
<br />
Update and check your Clam Antivirus with this command. This is normally done automatically every hour via cron.<br />
freshclam -v<br />
<br />
or<br />
freshclam --debug<br />
<br />
Verify hourly update checking by viewing the freshclam/current log file via the Server-Manager View Log Files panel.<br />
<br />
'''Realtime Blackhole Lists and DNS Blacklists'''<br />
<br />
To view the settings for the RBL and DNSBL, use this command:<br />
config show qpsmtpd<br />
<br />
If you followed the instructions above, both checks are enabled.<br />
<br />
To see the log of these tests, use a command like:<br />
tail /var/log/qpsmtpd/current | tai64nlocal <br />
<br />
To specify multiple RBLs, use a command like this:<br />
config setprop qpsmtpd RBLList \<br />
bl.spamcop.net,combined.njabl.org,dnsbl.ahbl.org,dnsbl-1.uceprotect.net,\<br />
list.dsbl.org,multihop.dsbl.org,psbl.surriel.com,zen.spamhaus.org<br />
<br />
Note: we have had trouble with the uceprotect.net level 2 list and sometimes remove it from the list as shown here.<br />
<br />
To enable or disable both available lists, use something like:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
<br />
To confirm any configuration changes and enact them:<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
'''More Information'''<br />
<br />
Introduction to Antispam Practices - [http://www.howtoforge.com/introduction_antispam_practices| here]<br />
<br />
Here is another great [http://mirror.contribs.org/smeserver//contribs/rmitchell/smeserver/howto/Spam%20blocking%20HOWTO%20using%20qpsmtpd%20&%20RBL%20for%20sme%20server.htm] howto.<br />
<br />
Informative URLs:<br />
* http://forums.contribs.org/index.php?topic=35178.0 <br />
* http://forums.contribs.org/index.php?topic=31278.0<br />
* http://forums.contribs.org/index.php?topic=31279.0<br />
* http://forums.contribs.org/index.php?topic=32158.0<br />
* http://mirror.contribs.org/smeserver/contribs/michaelw/sme7/<br />
* http://mirror.contribs.org/smeserver/contribs/bread/mailstats/<br />
* http://wiki.apache.org/spamassassin/BayesInSpamAssassin<br />
* Enter this command at a console:<br />
perldoc Mail::SpamAssassin::Conf <br />
Last Updated ( Thursday, 21 June 2007 )<br />
<br />
===Email Clients===<br />
===="concurrency limit reached" when using IMAP====<br />
Sometime shows as Thunderbird giving this error message,<br />
''This Mail-server is not a imap4 mail-server''<br />
<br />
To workaround thunderbirds limitations change, this thunderbird setting to false<br />
* Preferences, Advanced, Config editor (aka about:config): filter on tls.<br />
* set security.enable_tls to false<br />
<br />
You can also increase the ConcurrencyLimitPerIP and/or ConcurrencyLimit value for imap and/or imaps (secure)<br />
config setprop imap ConcurrencyLimitPerIP 20<br />
config setprop imaps ConcurrencyLimitPerIP 20<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
check<br />
config show imap<br />
tail -f /var/log/imap/current | tai64nlocal<br />
<br />
More detail can be found [http://forums.contribs.org/index.php?topic=33124.0 here].<br />
<br />
====Mail server is not an IMAP4 mail server====<br />
This is a bug in Thunderbird, the previous tips may help<br />
<br />
====The Bat====<br />
The gives this error message, but they are wrong.<br><br />
"This server uses TLS v3.0 which is considered to be obsolete and insecure. <br />
The server must use TLS v3.1 or above."<br />
<br />
<br />
====Outlook/Outlook Express give error 10060/0x800CCC90====<br />
Most likely OUTLOOK (EXPRESS) isn't configured correctly.<br />
<br />
-open OUTLOOK<br />
-click TOOLS > ACCOUNTS<br />
-click CHANGE (on the right-hand side)<br />
-find INCOMING MAIL SERVER & OUTGOING MAIL SERVER (on right-hand side)<br />
-type: mail.yourdomain.tld (in both places)<br />
-click MORE SETTINGS (on bottom-right)<br />
-click OUTGOING SERVER tab (at the top)<br />
-checkmark "MY OUTGOING SERVER REQUIRES AUTHENTICATION"<br />
-bullet "USE SAME SETTINGS AS INCOMING MAIL SERVER"<br />
-click ADVANCED tab (at the top)<br />
-find OUTGOING SERVER<br />
-checkmark "THIS SERVER REQUIRES A SECURE CONNECTION" (under outgoing server)<br />
-change 25 to 465<br />
-[possibly required, secure IMAP is 993]<br />
-click OK > NEXT > FINISHED<br />
-you're finished, your email should work now<br />
<br />
====Outlook test message doesn't come through====<br />
You clicked the TEST ACCOUNT SETTINGS in OUTLOOK didn't you? This is a bug in OUTLOOK. The test message sends a test email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. To test, send an actual message from OUTLOOK.<br />
<br />
If you want, you can try THUNDERBIRD. It's like OUTLOOK but made by a different company. It's completely free and works very well at home and at the office.<br />
<br />
====I can't receive/send email from my application (ACT!, vTiger, MS Outlook, etc)====<br />
Most likely, this is a bug the application you're using and not a problem with the SMESERVER. The application sends an email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. <br />
<br />
As a workaround you can disable the check for the 'Date header'.<br />
To disable this check on the internal interface:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
To disable this check for the external interface: <br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
====After I upgrade my SME Server, my email folders have disappeared when using IMAP====<br />
After upgrade, if there are missing IMAP folders, the client may need to re-subscribe to folders. This may affect either webmail users or users who use an IMAP email client.<br />
<br />
====Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4====<br />
The main problem here is that Microsoft has decided that Entourage will only support trusted, PEM Base-64 Encoded certificates. To use IMAPS or SMTPS from Entourage with your SME server, you will need to:<br />
1. Login to your Mac as a user with administrative privileges<br />
<br />
2. Open Safari and browse to https://''smeserver''/server-manager. <br />
When you receive the warning about your certificate:<br />
- click on "Show Certificate"<br />
- click and drag the gold-rimmed image of a certificate to your desktop. <br />
You will now have ''myserver.mydomain.tld.cer'' on your desktop.<br />
<br />
3. Locate and open the '''Microsoft Cert Manager'''<br />
- "Import" the certificate you downloaded in step 2.<br />
<br />
4. Highlight the imported certificate and "Export" it. <br />
- Select the "PEM..." format<br />
- add "''pem.''" to the beginning of the filename<br />
- export it to your Desktop<br />
<br />
5. Double-click on the new ''pem.myserver.mydomain.tld.cer'' <br />
- Apple's '''Keychain Access''' application will open.<br />
- Select the '''X509Anchors''' Keychain and click "OK"<br />
<br />
6. While still in Apple's '''Keychain Access''', select the "Certificates" category<br />
- Drag ''pem.myserver.mydomain.tld.cer'' into the certificates window.<br />
<br />
You should now be able to connect to your SME from your Entourage using IMAPS. <br />
<br />
If you are accessing your SME server using a different name than the one encoded in the certificate you will still receive a security warning from Entourage, but "OK" will now grant access to your folders.<br />
<br />
Notes: <br />
* Procedure mostly taken from http://www.kerio.com/manual/kmsug/en/ch09s06.html<br />
* I still get various other IMAP errors due, I suspect, to the "concurrency limit reached" issue.<br />
* Click on "Show Keychains" in Apple's "Keychain Access" if you need to delete a certificate and try again.<br />
<br />
====How do I get my e-mail to show the correct From Address====<br />
<br />
The From address on an e-mail is not supplied by the server. It is supplied by the e-mail client.<br />
<br />
* Configure your Account in your e-mail client with the correct FROM address.<br />
* You can change the FROM address in webmail with the following:<br />
**Login to webmail as the user, go to ''options-personal information'' and change the ''identity'' to have the correct FROM address. You can have multiple identities with a single user.<br />
<br />
===Server Settings===<br />
====Double bounce messages====<br />
To stop admin receiving double bounce messages<br />
<br />
config setprop qmail DoubleBounceTo someoneuser<br />
signal-event email-update<br />
<br />
Or just delete them. You risk losing legitimate double bounces (which are<br />
rare, but you want to look at them when they do occur)<br />
<br />
config setprop qmail DoubleBounceTo devnull<br />
signal-event email-update<br />
<br />
see a longer explaination [[Email_delete_double-bounce_messages | here]]<br />
<br />
====Keep a copy of all emails====<br />
You may need to keep a copy of all emails sent to or from your email server.<br />
This may be for legal, or other reasons.<br />
<br />
The following instructions will create a new user account (maillog) and forward every email that goes through your SME server to it.<br />
<br />
First, log onto the server-manager and create the user '''maillog'''<br />
<br />
Go to the SME Command Line (logon as root) and issue the following commands:<br />
<br />
config setprop qpsmtpd Bcc enabled<br />
signal-event email-update<br />
<br />
Optionally make the forwarding of the emails invisible to the end user. Without it, there will be an X-Copied-To: header in each email. Run this command before the signal-event<br />
<br />
config setprop qpsmtpd BccMode bcc<br />
<br />
If you want to view the emails, point your email client at the SME and log on as maillog.<br />
<br />
====Set max email size====<br />
There are several components involved in sending email on a SME server. Each component has a size limit that may affect an email message that passes through the server.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
! Subsystem<br />
! Function<br />
! Default Limit<br />
! Command to change size<br />
! Notes<br />
|-<br />
|qmail<br />
|Delivers email to local mailboxes and to remote servers<br />
|15000000<br />
|config&nbsp;setprop&nbsp;qmail&nbsp;MaxMessageSize&nbsp;xx000000<br />
|Value is in BYTES. 15000000 equals approximately 15MB<br />
|-<br />
|clamav<br />
|Used to scan emails and attachments<br />
|15M<br />
|config&nbsp;setprop&nbsp;clamav&nbsp;MaxFileSize&nbsp;15M<br />
|value includes human-readable abbreviations. "15M" equlas 15 MegaBytes.<br />
|-<br />
|qpsmtpd<br />
|The clamav plugin to qpsmtpd is called with a specified size limit.<br />
|25000000<br />
|config&nbsp;setprop&nbsp;qpsmtpd&nbsp;MaxScannerSize&nbsp;xx000000<br />
|Value is in BYTES.<br>Question: does this value override the setting of 'MaxFileSize', or will the smaller value prevail?<br />
|-<br />
|php<br />
|The php maximum file upload size will determine the largest file you can attach to an email message using horde (or any other php email client)<br />
|10M<br />
|config&nbsp;setprop&nbsp;php&nbsp;UploadMaxFilesize&nbsp;10M<br />
|<br />
|-<br />
|}<br />
A note about clamav:<br><br />
ClamAV includes settings to prevent the scanning of archives that could cause problems if fully expanded; if an attachment cannot be scanned, it will be rejected.<br />
<br />
These attributes could result in the rejection of a compressed attachment on a SME server:<br />
* ArchiveMaxCompressionRatio (default 300)<br />
* MaxFiles (default 1500)<br />
* MaxRecursion (default 8)<br />
<br />
====Add the admin user as an administrator for Horde====<br />
<br />
config setprop horde Administration enabled <br />
signal-event email-update<br />
<br />
==== Large attachments not displaying in webmail ====<br />
Due to limits set in the PHP configuration it might be that webmail will not display large attachments (see also [[bugzilla:3990]]). The following entries are related to the error and can be found in the log files:<br />
<br />
'''/var/log/messages'''<br />
Mar 13 00:00:12 box1 httpd: PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 154 bytes) in /home/httpd/html/horde/imp/lib/MIME/Contents.php on line 173<br />
<br />
'''/var/log/httpd/error_log'''<br />
Allowed memory size of 33554432 bytes exhausted (tried to allocate 0 bytes)<br />
<br />
The default MemoryLimit setting in PHP is set to 32M the value can be changed using the commands below replacing ''XX'' with the value you desire.<br />
{{Note box|You can set the MemoryLimit any value you like but be sure to add the capital M as a suffix for Megabytes.}}<br />
db configuration setprop php MemoryLimit XXM<br />
expand-template /etc/php.ini<br />
sv t httpd-e-smith<br />
<br />
====Disable mail to a user from an external network====<br />
Can be either a user, pseudonym or group<br />
db accounts setprop groupname/username Visible internal<br />
signal-event email-update<br />
<br />
====I can't receive mail at: user@mail.domain.tld====<br />
Add mail.domain.tld as a virtualdomain.<br />
-login to SERVER-MANAGER<br />
-click DOMAINS (on the left)<br />
-click ADD<br />
-type: mail.domain.tld<br />
<br />
====How do I find out who is logged into webmail and what IP number.====<br />
This is logged is in /var/log/messages.<br />
<br />
====How do I enable smtp authentication for users on the internal network.====<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cp /etc/e-smith/templates/var/service/qpsmtpd/config/peers/0/05auth_cvm_unix_local .<br />
signal-event email-update<br />
(note the "." at the end of the 3rd line)<br><br />
Authentication for the local network will now follow the setting of config::qpsmtpd::Authentication<br />
<br />
====How do I disable SMTP relay for unauthenticated LAN clients====<br />
http://forums.contribs.org/index.php?topic=38797.msg176490#msg176490<br />
* Enable smtp authentication as shown above<br />
* Disable un-authenticated smtp relay for the local network(s)using:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients<br />
echo "# SMTP Relay from local network denied by custom template" >\<br />
/etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients/80relayFromLocalNetwork<br />
signal-event email-update<br />
<br />
* Configure your email clients to use smtps with authentication:<br><br />
- change outgoing smtp port to 465 and select SSL<br><br />
- enable Authentication against the outgoing mail server<br />
<br />
<br />
====Internet provider's port 25 is blocked: How to set an alternative port for the SMTP server====<br />
If your provider is blocking smtp port 25 on your internet connection but your hosting provider is offering an alternative port (or when using some relay service) you can simply set this alternative port by adding it to the 'Address of Internet provider's mail server' value in the 'E-mail delivery settings' screen of the server-manager like this:<br />
<internet providers mail server name or ip-address>:<alternative port><br />
For example: mail.mydomain.com:587<br />
<br />
====How do I enable and configure a disclaimer in email messages====<br />
<br />
<br />
A disclaimer message can be added to the footer of all outgoing email messages.<br />
<br />
The message can be the same for all domains or it can be different for all domains.<br />
<br />
This functionality is part of sme7.2 release so make sure you have upgraded before doing this.<br />
<br />
To create a general disclaimer for all domains on your sme server<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer<br />
Enter the required disclaimer text <br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
To make the changes take effect<br />
signal-event email-update<br />
<br />
<br />
To create domain specific disclaimers, create seperate domain based disclaimer text files<br />
<br />
Delete the general (all domains) disclaimer file if you have already created it<br />
rm /service/qpsmtpd/config/disclaimer<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer_domain1.com.au<br />
pico -w /service/qpsmtpd/config/disclaimer_domain2.com<br />
pico -w /service/qpsmtpd/config/disclaimer_domain3.org<br />
<br />
Enter the required text in each disclaimer file<br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
After making any changes remember to do<br />
signal-event email-update<br />
<br />
<br />
Note if you only wish to have a disclaimer for some domains, then only create a disclaimer text file for those domains <br />
<br />
<br />
Note also the criteria for when a disclaimer is attached <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648)<br />
<br />
eg a disclaimer is added to internal to external messages but not internal to internal messages.<br />
<br />
There are also various switches that can be applied <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648).<br />
<br />
<br />
To disable the disclaimer function for all domains on your sme server<br />
config setprop smtpd disclaimer disabled<br />
signal-event email-update<br />
<br />
<br />
====Email WBL server manager panel====<br />
<br />
There is a server manager contrib to allow GUI control of email white and black lists.<br />
<br />
The panel allows easy configuration of functionality that is built into qmail, qpsmtpd and spamassassin. For more information google for qmail & qpsmtpd, read the spamassassin section in this wiki article and see [http://wiki.contribs.org/Email#Default_Plugin_Configuration default qpsmtpd plugin confguration]).<br />
<br />
{{Warning box|It is a test release, although it has been in use since Jan 2007 and appears functionaly stable. To install do:<br />
wget http://mirror.contribs.org/smeserver/contribs/dmay/smeserver/7.x/testing/smeserver-wbl/smeserver-wbl-0.0.1-a8.dmay.noarch.rpm <br />
rpm -Uvh smeserver-wbl*.rpm<br />
}}<br />
<br />
There are two main sections, Reject and Accept, where you can control settings.<br />
<br />
Reject - Black lists are used for rejecting e-mail traffic<br />
<br />
DNSBL status - DNSBL is an abbreviation for "DNS blacklist". <br />
It is a list of IP addresses known to be spammers.<br />
RHSBL status - RHSBL is an abbreviation for "Right Hand Side Blacklist". <br />
It is a list of domain names known to be spammers.<br />
qpsmtpd badhelo - Check a HELO message delivered from a connecting host. <br />
Reject any that appear in badhelo during the 'helo' stage.<br />
qmail badmailfrom - Check envelope sender addresses. <br />
Reject any that appear (@host or user@host) in badmailfrom during the 'mail' <br />
stage.<br />
<br />
Accept - White lists are used for accepting e-mail traffic<br />
<br />
Whitelists status - White Lists: ACCEPT<br />
qpsmtpd whitelisthosts - Any IP address listed in whitelisthosts will be exempted <br />
from any further validation during the 'connect' stage.<br />
qpsmtpd whitelisthelo - Any host that issues a HELO matching an entry in whitelisthelo <br />
will be exempted from further validation during the 'helo' stage.<br />
qpsmtpd whitelistsenders - Any envelope sender of a mail (@host or user@host) matching an <br />
entry in whitelistsenders will be exempted from further validation<br />
during the 'mail' stage.<br />
spamassassin whitelist_from - Any envelope sender of a mail (*@host or user@host) matching an <br />
entry in whitelist_from will be exempted from spamassassin rejection.<br />
<br />
<br />
After making any changes using this panel you must click both the Save and Update buttons, in order for changes to take effect.<br />
<br />
===External Access===<br />
====Allow external IMAP mail access====<br />
There was a deliberate decision to remove non-SSL protected username/password<br />
services from the external interface.<br />
<br />
to allow unsecure IMAP access<br />
<br />
config setprop imap access public<br />
signal-event email-update<br />
<br />
But before you do this try to use secure IMAP<br><br />
fixme: explain how<br />
<br />
====POP3 & webmail HTTP====<br />
I want to set my SMESERVER to allow POP3 (or webmail HTTP) but it's not an option, I only see POP3S (or webmail HTTPS).<br />
<br />
The SMESERVER is secure by design. POP3 (or webmail HTTP) is viewed as inadequate security and removed as an option from a standard installation to encourage unknowing administrators to select the 'best practice' option -a secure connection with POP3S, IMAPS, or HTTPS.<br />
<br />
You can still set your SMESERVER to allow POP3 settings by:<br />
config setprop pop3 access public<br />
signal-event email-update<br />
<br />
====Allow external pop3 access====<br />
<br />
Email settings > POP3 server access in SME 7.1 server-manager allows only pop3s protocol for clients outside the LAN. Some email clients (eg The Bat! v3.98.4) won't allow pop3s connections to SME 7.1 because of ssl version conflict. Until this is sorted out, a workaround is to hack SME to allow regular pop3 on the external interface using the following commands. <br />
<br />
config setprop pop3 access public<br />
signal-event email-update<br />
svc -t /service/pop3s <br />
<br />
more information [[bugzilla:2620]]<br />
<br />
===Imap===<br />
====Folders with a dot in name====<br />
Email folder names that have a period ('.') in the folder name, will be split into sub-folders.<br />
e.g. folder name 'www.contribs.org' is created as<br />
www<br />
contribs<br />
org<br />
<br />
===qpsmtpd===<br />
SME uses the [http://smtpd.develooper.com qpsmtpd] smtp daemon.<br />
<br />
====Official Description====<br />
qpsmtpd is a flexible smtpd daemon written in Perl. Apart from the core SMTP features, all functionality is implemented in small "extension plugins" using the easy to use object oriented plugin API.<br />
<br />
qpsmtpd was originally written as a drop-in qmail-smtpd replacement, but now it also includes smtp forward, postfix, exim and maildir "backends".<br />
<br />
qpsmtpd wiki: http://wiki.qpsmtpd.org <br />
<br />
<br />
====Default Plugin Configuration====<br />
SME uses the following [http://wiki.qpsmtpd.org/plugins qpsmtpd plugins] to evaluate each incoming email. <br />
<br />
SME maintains 2 distinct configurations: one for the 'local' networks (as defined in server-manager::Security::Local networks) and another for 'remote' networks (everyone else).<br />
<br />
The default configuration of each plugin is indicated in the 'Default Status' column.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
!Plugin<br />
!Purpose<br />
!Default Status<br />
|-<br />
|hosts_allow<br />
|Prohibit more than "InstancesPerIP" connections from any single host (change with 'config setprop smtp InstancesPerIP'). Allow or deny connections according to the contents of /var/service/qpsmtpd/config/hosts_allow. See [http://svn.perl.org/qpsmtpd/trunk/plugins/hosts_allow hosts_allow SVN code] for more details.<br />
|[http://bugs.contribs.org/show_bug.cgi?id=3352 upcoming]<br />
|-<br />
|peers<br />
|Allow different plugin configuration based on the sending computer's IP address. By default SME maintains different configurations for the local networks (in /var/service/qpsmtpd/config/peers/local) and for everyone else (in /var/service/qpsmtpd/config/peers/0)<br />
|enabled<br />
|-<br />
|logging/logterse<br />
|Allow greater logging detail using smaller log files<br />
|enabled<br />
|-<br />
|auth/auth_cvm_unix_local<br />
|Allow authenticated smtp relay<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_earlytalker<br />
|reject email from servers that talk out of turn<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|count_unrecognized_commands<br />
|reject email from servers that issue ''X'' invalid commands<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|bcc<br />
|bcc all email to a specific address for archiving<br />
|'''disabled'''<br />
|-<br />
|check_relay<br />
|Check to see if relaying is allowed (in case the recipient is not listed in one of SME's local domains)<br />
|enabled<br />
|-<br />
|check_norelay<br />
|Check to see if the sending server is specifically forbidden to relay through us.<br />
|enabled<br />
|-<br />
|require_resolvable_fromhost<br />
|Check that the domain listed in the sender's email address is resolvable<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_basicheaders<br />
|reject email that lacks either a From: or Date: header<br />
|enabled<br />
|-<br />
|rhsbl<br />
|Reject email if the sender's email domain has a reputation for disregarding smtp RFCs.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|dnsbl<br />
|Reject email from hosts listed in your configured dnsbl servers<br />
|'''disabled'''<br />
|-<br />
|check_badmailfrom<br />
|Reject email where the sender address is listed in /var/service/qpsmtpd/config/badmailfrom<br />
|enabled<br />
|-<br />
|check_badrcptto_patterns<br />
|Reject email addressed to any address matching an expression listed in /var/service/qpsmtpd/config/badrcptto_patterns<br />
|enabled<br />
|-<br />
|check_badrcptto<br />
|Reject email addressed to any address listed in /var/service/qpsmtpd/config/badrcptto<br />
|enabled<br />
|-<br />
|check_spamhelo<br />
|Reject email from hosts that say 'helo ...' using a value in /var/service/qpsmtpd/config/badhelo<br />
|enabled<br />
|-<br />
|check_smtp_forward<br />
|If ''config show DelegateMailServer'' or ''db domains show <domainname> MailServer'' is set (telling SME to deliver email for all domains or just <domainname> to another server), check_smtp_forward will connect to the specified server and will reject the message outright if the internal mail server would also reject it.<br />
|'''disabled'''<br>unless an internal mail server is configured.<br />
|-<br />
|check_goodrcptto<br />
|Accept email only if the recipient address matches an entry in /var/service/qpsmtpd/config/goodrcptto. For domains that are configured to use an internal mail server, the entire domain name will be added to .../goodrcptto.<br />
|enabled<br />
|-<br />
|rcpt_ok<br />
|Return 'OK' if none of the other host checks has returned 'DENY' (??)<br />
|enabled<br />
|-<br />
|pattern_filter<br />
|Reject email according to content patterns (??)<br />
|'''disabled'''<br />
|-<br />
|tnef2mime<br />
|Convert MS TNEF (winmail.dat) and uuencoded attachments to MIME<br />
|enabled<br />
|-<br />
|disclaimer<br />
|Add a configurable disclaimer to email messages<br />
|'''disabled'''<br />
|-<br />
|spamassassin<br />
|Check email using spamassassin, and optionally reject it completely if the score exceeds a configurable value.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|virus/clamav <br />
|Scan incoming email with ClamAV<br />
|enabled<br />
|-<br />
|queue/qmail-queue<br />
|Deliver the incoming message to qmail for delivery.<br />
|enabled<br />
|-<br />
|}<br />
<br />
===Internal Mail Servers===<br />
SME can be configured as a spam and antivirus filter for one or more "Internal" mail servers on a domain-by-domain basis. The mail server specified does not have to be on the same local network as your SME server.<br />
<br />
====Deliver ALL email to a single internal mail server====<br />
You can deliver all email for all domains on your SME server to a single internal mail server by setting the mail server address in server-manager::Configuration::E-mail::Change e-mail delivery settings::Address of internal mail server.<br />
<br />
====Deliver email for one domain to an internal mail server====<br />
You can also configure only a single domain to use an internal mail server, or you can configure different domains to use different internal mail servers.<br />
<br />
First, create the necessary virtual domains using server-manager::Configuration::Domains::Add Domain.<br />
<br />
Then, (assuming your domain is called ''test.com'' and the actual mail server is at ''a.b.c.d'' issue the following commands:<br />
db domains setprop test.com MailServer a.b.c.d<br />
signal-event email-update<br />
<br />
=== Secondary/Backup Mail Server Considerations ===<br />
<br />
Many people misunderstand the issues of using a secondary or backup <br />
mail server (backup MX) to hold your mail before it gets delivered <br />
to your SME Server. If you consider putting a backup mail server in <br />
place because you are concerned about lost mail because your internet<br />
connection may occasionally drop out, think again and consider the issues<br />
discussed below.<br />
<br />
====What is ''Backup MX''====<br />
<br />
A backup MX is a system whereby through your DNS records you tell other<br />
servers on the internet that in order to deliver mail to your domain they<br />
first need to try the primary MX record and if they fail to connect they<br />
can try to connect to one or more of your listed backup or secondary mail <br />
servers. See also http://en.wikipedia.org/wiki/MX_record<br />
<br />
====The process of delivering email to your SME Server====<br />
<br />
So lets look at how mail gets delivered without and with a <br />
''backup mx'' when your Internet link, ISP or server is down.<br />
<br />
====='''Without''' a backup MX=====<br />
<br />
* The sending mail server cannot connect to your server.<br />
* The sending mail server MUST queue the mail and try again later.<br />
* The mail stays on the sender's server.<br />
* The sender's server resends the mail at a later date.<br />
<br />
''The requirement to re-queue is a fundamental part of the SMTP protocol - <br />
it is not optional. So, if your server is '''offline''' due to a link or ISP <br />
outage, '''the mail just stays at the sender's server until you are once <br />
again reachable'''.<br />
<br />
====='''With''' a backup MX=====<br />
<br />
* The sending mail server cannot contact your server.<br />
* The sending mail server sends the mail to your secondary MX.<br />
* The secondary MX queues the mail until your link/server is up.<br />
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'').<br />
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs.<br />
* You have no, or little, visibility over the queued mail.<br />
* When your link comes up, the secondary MX sends the mail on to your server.<br />
* You have added more hops, more systems and more delay to the process.<br />
<br />
If you think that a backup MX will protect against broken mail servers <br />
which don't re-queue, you can't. Those servers will drop mail on the floor<br />
at random times, for example when ''their'' Internet link is down. <br />
<br />
Those servers are also highly likely to never try your backup MX. <br />
<br />
Thankfully those servers are mostly gone from the Internet, but adding a <br />
secondary MX doesn't really improve the chances that they won't drop mail<br />
destined for your server on the floor.<br />
<br />
====Backup MX and SPAM Filtering====<br />
<br />
On top of the issue, indicated above, there is another issue to consider<br />
and that is what happens with SPAM due to the use of a ''Backup MX''. <br />
<br />
Your SME Server takes care of filtering a lot of SPAM by checking on the full <br />
username & domain at the time it is received.<br />
<br />
For example if your server hosts '''example.com''' and someone sends <br />
mail to '''joeuser@example.com''', the server will '''only''' accept the mail<br />
if joeuser is a local user/alias/group/pseudonym on the server. <br />
Otherwise, the mail is rejected during the SMTP transaction.<br />
<br />
A backup mail server however, generally does not have a full list of<br />
users against which it can check if it should accept the mail for the given<br />
domain. Hence it will accept mail for ''invalid'' users.<br />
<br />
So:<br />
<br />
* If you trust the secondary MX, you <u>will</u> accept a lot of SPAM when the link comes up.<br />
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.<br />
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.<br />
<br />
The SPAM backscatter can only be stopped if the secondary MX has a full list<br />
of users for your domain to allow filtering to occur.<br />
<br />
But:<br />
<br />
* You need to be able to configure this secondary MX with such user/domain lists<br />
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration<br />
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.<br />
<br />
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find <br />
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail. <br />
<br />
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.<br />
<br />
* If you bounce mail at your server, you have logs to show what's wrong. <br />
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.<br />
<br />
==== Summary ====<br />
<br />
In summary, if your server/Internet connection is available most (let's say >90%) of <br />
the time, you are generally better off <u>without a secondary MX</u>. <br />
<br />
If your server/link is down more than this (e.g. dialup), you should not be delivering mail <br />
directly to your server.<br />
<br />
If you still want to consider setting up a seconday MX, ensure that:<br />
<br />
* you have fully control of the configuration of each of the email gateways for your domain<br />
* each gateway can make decisions on whether to accept/reject mail for the users at the domain<br />
<br />
===User accounts===<br />
====Multiple users with the same name on different domains====<br />
''The Manuel contains a detailed explanation here [http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter9#Pseudonyms], however, this question is frequently asked in the forums and this FAQ was added in response to this thread [http://forums.contribs.org/index.php?topic=41558.0;all]''<br />
<br />
SME only supports one name set, so you cannot have multiple user accounts for the same user (eg joe) at different domains, you can only have one user account for joe which applies to all domains.<br />
<br />
The workaround is to create user accounts with a different name to what will be used as an email address.<br />
<br />
eg.<br />
*create user account joe1<br />
*create user account joe2<br />
*create user account joe3<br />
<br />
'''DO NOT create a user account for joe'''<br />
<br />
*create pseudonym for joe@domain1 which forwards to user account joe1<br />
*create pseudonym for joe@domain2 which forwards to user account joe2<br />
*create pseudonym for joe@domain3 which forwards to user account joe3<br />
<br />
joe1 logs in using joe1 but advertises their email address as joe@domain1<br />
<br />
Your main or primary domain is created during initial setup in the admin console, Configure this server. <br />
Your additional domains are created using the Domains panel, and are called Virtual domains, but they function virtually identically to the main domain. In the Domains panel, you select an ibay for the content that will apply to virtual domain web sites.<br />
<br />
<br />
The mail server accepts mail for all valid domains (either the main or virtual), and delivers the mail to end user acounts or pseudonym addresses.<br />
<br />
Note, you do not need to use pseudonyms.<br />
<br />
You can just do the following.<br />
*create user account joe1 with effective email address of joe1@domain1<br />
*create user account joe2 with effective email address of joe2@domain2<br />
*create user account joe3 with effective email address of joe3@domain3<br />
<br />
This arrangement will work fine, but note that if email is inadvertantly sent to joe2@domain1 then joe2 will still receive that email (rather than joe1).<br />
External users would not really be sending to joe2@domain1 as that address has never been advised to anyone as being active.<br />
<br />
<noinclude>[[Category:Howto]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=Email&diff=10260
Email
2008-07-17T15:16:24Z
<p>Mercyh: /* Email */</p>
<hr />
<div>==Email==<br />
===Spam===<br />
====Spamassassin====<br />
Set spamassassin for automatically delete junkmail.<br />
You can change the "days" that spamassassin sets to automatically delete junkmail, to delete after two months <br />
<br />
db configuration setprop spamassassin MessageRetentionTime 60 <br />
signal-event email-update <br />
<br />
<br />
The "Custom spam rejection level" will only work when "Spam sensitivity" is set to custom.<br />
<ol></li><li>Open server-manager.<br />
</li><li>Click e-mail in the navigation pane (left-hand side).<br />
</li><li>Click Change e-mail filtering settings.<br />
</li><li>Change "Spam sensitivity" to custom and adjust the settings to your liking.<br />
</li></ol><br />
<br />
This happens because by default, no mail (except for viruses) gets rejected without the admin doing something first.<br />
<br />
====='''X-Spam-Level Header in Email Messages'''=====<br />
SME does not create an X-Spam-Level header in processed email messages by default.<br />
<br />
To enable this capability:<br />
/usr/bin/yum install --enablerepo=smecontribs smeserver-qpsmtpd-spamassassinlevelstars<br />
signal-event email-update<br />
<br />
(Based on [[Bugzilla:3505]])<br />
<br />
=====Custom Rule Scores=====<br />
You can customize the score assigned by a specific Spamassassin rule (SARE_ADULT2 in this case) as follows:<br />
mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
echo "score SARE_ADULT2 20.000" >> 20localscores<br />
signal-event email-update<br />
<br />
You can now add additional tests and custom scores by editing the newly-created template fragment ''20localscores'' and adding new custom scores using:<br />
pico -w /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
Each custom score goes on its own line. If you enter a score surrounded by parentheses, the "custom" score will be added to the default score for the specified test (use ''score TEST_NAME (-1)'' to reduce the score for 'TEST_NAME' by 1) <br />
<br />
You can remove these customizations using: <br />
rm -f /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
<br />
References:<br />
* http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#scoring_options<br />
* http://spamassassin.apache.org/tests_3_2_x.html<br />
* http://www.rulesemporium.com/<br />
<br />
====Real-time Blackhole List (RBL)====<br />
Enabling RBL's <br><br />
RBL's are disabled by default to allow maximum accommodation (your ISP may be on a RBL & you may not know it). You can enable RBL's by:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
signal-event email-update<br />
<br />
You can see your RBL's by:<br />
config show qpsmtpd<br />
<br />
You can add to your RBL's by:<br />
config setprop qpsmtpd RBLList <rbl-list-name><br />
signal-event email-update<br />
<br />
Many will argue what's best but most would agree that you can set best-practice recommended settings by:<br />
config setprop qpsmtpd RBLList zen.spamhaus.org:whois.rfc-ignorant.org:dnsbl.njabl.org<br />
signal-event email-update<br />
<br />
Note: More information on this topic can be found here:<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#RHSBL_Servers]<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#DNSBL_Servers]<br />
<br />
====Server Only====<br />
Some of the spam filter rules cannot work unless the SMESERVER knows the external IP of the box. If you put a SMESERVER in server-only mode behind other firewalls, it will lose some of the anti-spam rules. For example, the rule that blocks attempts where spammers try "HELO a.b.c.d" where a.b.c.d is your external IP address.<br />
<br />
Unfortunately, many admins believe that port-forwarding SMTP provides additional security. It doesn't, it limits the SMESERVER's ability to apply some rules.<br />
<br />
<br />
====I want to enable GreyListing====<br />
GreyListing support is under the covers and can easily be enabled for those who know what they are doing. However, many experienced users found that they spent more time looking after the greylisting configuration than they received in benefit.<br />
<br />
====Setup Blacklists & Bayesian Autolearning====<br />
<br />
(Much of what follows has been shamelessly copied from the Sonoracomm howto)<br />
<br />
The default SME settings (as you can see [http://wiki.contribs.org/Email#Default_Plugin_Configuration here]) do not include DNSBL filtering, spam rejection, or (which is not obvious from the above) bayesian filtering in spamassassin to allow spamassassin to learn from received email and improve over time.<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set<br />
thresholds for the bayesian filter.<br />
<br />
config setprop spamassassin UseBayes 1<br />
config setprop spamassassin BayesAutoLearnThresholdSpam 4.00<br />
config setprop spamassassin BayesAutoLearnThresholdNonspam 0.10<br />
expand-template /etc/mail/spamassassin/local.cf<br />
sa-learn --sync --dbpath /var/spool/spamd/.spamassassin -u spamd<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes_*<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes.mutex<br />
chmod 640 /var/spool/spamd/.spamassassin/bayes_* <br />
config setprop qpsmtpd DNSBL enabled<br />
config setprop qpsmtpd RHSBL enabled<br />
config setprop spamassassin status enabled<br />
config setprop spamassassin RejectLevel 12<br />
config setprop spamassassin TagLevel 4<br />
config setprop spamassassin Sensitivity custom<br />
signal-event email-update<br />
<br />
These commands will:<br />
* enable spamassassin<br />
* configure spamassassin to reject any email with a score above 12<br />
* tag spam scored between 4 and 12 in the email header<br />
* enable bayesian filter<br />
* 'autolearn' as SPAM any email with a score above 4.00<br />
* 'autolearn' as HAM any email with a score below 0.10<br />
* enable RHSBL using the default SBLList. Note that rhsbl checking has been known to place a heavy burden on SME servers.<br />
* enable DNSBL using the default RBLList<br />
<br />
====The entire Sonoracomm howto from Google's text cache====<br />
* The Sonoracomm HowTo has been a very well regarded set of instructions for SME mail server configuration for quite a while.<br />
<br />
* This section was created during an extended outage of the Sonoracomm web server (in 2007?)<br />
<br />
* The Sonoracomm HowTo has been updated since this section was created, and is well worth examining. View the current version at: http://www.sonoracomm.com/index.php?option=com_content&task=view&id=49&Itemid=32<br />
<br />
* The content below has been modified to include changes suggested in the bug tracker and forums.<br />
<br />
* These instructions are aimed mostly at configuring SME as the only mail server, not for using SME with an internal mail server. (Specifically, LearnAsSpam.pl is harder to configure when using an internal mail server - you would have to develop a method for getting the unmarked SPAM into an IMAP folder directly on the SME server itself. Not impossible, but difficult!)<br />
<br />
'''SONORA COMMUNICATIONS, INC.'''<br />
<br />
This is a quick configuration howto, not an in-depth look at SpamAssassin. Much more can be done<br />
beyond this document, but this will take a big dent out of your spam and free up CPU cycles on your server.<br />
<br />
See 'More Information' at the end.<br />
<br />
'''SpamAssassin'''<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set thresholds for the bayesian filter.<br />
<nowiki>rpm -Uvh \<br />
http://mirror.contribs.org/smeserver/contribs/\<br />
michaelw/sme7/smeserver-spamassassin-features-0.0.2-0.noarch.rpm</nowiki><br />
<br />
This command will install the FuzzyOCR SA plugin designed to catch those nasty image-based spam messages.<br />
yum -y --enablerepo=smeupdates-testing install FuzzyOcr<br />
<br />
'''Server-Manager'''<br />
<br />
Using the Server-Manager Configuration/E-Mail panel, adjust the settings to these reasonable <br />
* Virus scanning Enabled<br />
* Spam filtering Enabled<br />
* Spam sensitivity Custom<br />
* Custom spam tagging level 4<br />
* Custom spam rejection level 12<br />
* Sort spam into junkmail folder Enabled<br />
* Modify subject of spam messages Enabled<br />
<br />
It is also recommend blocking all executable content. To do so, select (highlight) all of the attachment types other than zip files (the last two).<br />
<br />
Click Save.<br />
<br />
'''How It Works'''<br />
<br />
When receiving an incoming message, the server first tests for RBL and DNSBL listings, if enabled. If the sender is blacklisted, the messages are blocked outright and Spamassassin never sees it. <br />
<br />
With this configuration, the spammiest messages, those marked as 12 or above, will be rejected at the SMTP level. Those spam messages marked between 4 and 12, will be routed to the users' (IMAP) junkmail folder. This is done so the users can check for false-positives...valid messages that were classified as spam by SpamAssassin.<br />
<br />
Users may check their junkmail folders for false-positives via webmail, or, if they are using an IMAP mail client, by simply checking the junkmail folder exposed by their mail client.<br />
<br />
https://servername/webmail<br />
<br />
'''Tweaking'''<br />
<br />
The server will automatically delete old spam in the junkmail folders after 90 days. You can control the number of days old spam is kept with the following commands. Where 15 is the number of days you want to keep messages, do...<br />
<br />
db configuration setprop spamassassin MessageRetentionTime 15<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
then<br />
<br />
config show spamassassin<br />
<br />
If you think you are losing misclassified mail, adjust the ''Custom spam rejection level'' higher.<br />
<br />
If too much spam is making through to your inbox, carefully adjust the 'Custom spam tagging level' down. Many people use the level 4. Anything below that may result in false-positives. YMMV.<br />
<br />
If too much spam is building up in your (IMAP) junkmail folder, adjust the 'Custom spam rejection level' down or change the number of days spam is kept in the junkmail folder before being automatically deleted by the server.<br />
<br />
'''Bayesian (Learning) Filter'''<br />
<br />
Install the LearnAsSpam.pl, (optional) mailstats and sa-update scripts, then configure nightly cron jobs like this:<br />
<nowiki>cd /usr/bin<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.pl<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/spamfilter-stats-7.pl<br />
cd /etc/cron.d<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.cron<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/mailstats.cron<br />
cd /etc/cron.daily<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/sa-update<br />
chmod +x sa-update<br />
/etc/rc.d/init.d/crond restart</nowiki><br />
<br />
Using an IMAP mail client, create a new folder called 'LearnAsSpam' (case sensitive). It can be created at the top level (like 'Inbox') or as a sub-folder. Create the folder for each user that will help train the Bayesian filter. Webmail will work fine for creating this folder, as well as for checking the junkmail (filtered mail or quarantine) folder.<br />
<br />
If any spam messages make it past the filter and into your inbox, just move them into the LearnAsSpam folder. A nightly cron job will process them and delete them for you. This is how you train the Bayesian filter.<br />
<br />
'''Testing'''<br />
<br />
You can check the auto-learning statistics with this command. You will be able to note the accumulation of the spam tokens (or not). Note that the Bayesian filtering must receive 200 spam messages before it starts to function, so don't expect instantaneous results.<br />
sa-learn --dump magic<br />
<br />
You can check the spam filter log with this command: <br />
tail -50 /var/log/spamd/current | tai64nlocal<br />
<br />
If you ever see an error such as:<br />
''warn: bayes: cannot open bayes databases /etc/mail/spamassassin/bayes_* R/W: tie failed: Permission denied''<br />
Try adjusting some permissions with these commands:<br />
chown :spamd /var/spool/spamd/.spamassassin/*<br />
chmod g+rw /var/spool/spamd/.spamassassin/* <br />
<br />
'''Whitelist and Blacklist'''<br />
<br />
If mail comes in and it is misclassified as spam (and moved to the junkmail folder when that feature is enabled), you can add the sender to the whitelist so that future messages coming in from that sender are not filtered.<br />
<br />
Conversely, you can add a spammer to the blacklist so you never see their spam again. <br />
<br />
Add senders (or their entire domains) to the global whitelist (or blacklist) with commands similar to these (as root):<br />
db spamassassin setprop wbl.global *@vonage.com White<br />
db spamassassin setprop wbl.global *domain2.com White<br />
db spamassassin setprop wbl.global badname@baddomain.com Black<br />
db spamassassin setprop wbl.global *@verybaddomain.com Black<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it White<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can enter multiple addresses/domains for both white and black lists in one command<br />
db spamassassin setprop wbl.global name@domain.com White *domain2.com White *domain3.com Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can view the lists with this command:<br />
db spamassassin show<br />
<br />
You can delete one or more entries from the white/blacklist using<br />
db spamassassin delprop wbl.global name@domain.com *domain2.com<br />
* name@domain.com and *domain2.com must exactly match a value in the output from ''db spamassassin show'' to the ''left'' of the equals sign. <br />
* You do not need to specify ''White'' or ''Black'' when deleting entries.<br />
<br />
<br />
<br />
'''Clam Antivirus'''<br />
<br />
Update and check your Clam Antivirus with this command. This is normally done automatically every hour via cron.<br />
freshclam -v<br />
<br />
or<br />
freshclam --debug<br />
<br />
Verify hourly update checking by viewing the freshclam/current log file via the Server-Manager View Log Files panel.<br />
<br />
'''Realtime Blackhole Lists and DNS Blacklists'''<br />
<br />
To view the settings for the RBL and DNSBL, use this command:<br />
config show qpsmtpd<br />
<br />
If you followed the instructions above, both checks are enabled.<br />
<br />
To see the log of these tests, use a command like:<br />
tail /var/log/qpsmtpd/current | tai64nlocal <br />
<br />
To specify multiple RBLs, use a command like this:<br />
config setprop qpsmtpd RBLList \<br />
bl.spamcop.net,combined.njabl.org,dnsbl.ahbl.org,dnsbl-1.uceprotect.net,\<br />
list.dsbl.org,multihop.dsbl.org,psbl.surriel.com,zen.spamhaus.org<br />
<br />
Note: we have had trouble with the uceprotect.net level 2 list and sometimes remove it from the list as shown here.<br />
<br />
To enable or disable both available lists, use something like:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
<br />
To confirm any configuration changes and enact them:<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
'''More Information'''<br />
<br />
Introduction to Antispam Practices - [http://www.howtoforge.com/introduction_antispam_practices| here]<br />
<br />
Here is another great [http://mirror.contribs.org/smeserver//contribs/rmitchell/smeserver/howto/Spam%20blocking%20HOWTO%20using%20qpsmtpd%20&%20RBL%20for%20sme%20server.htm] howto.<br />
<br />
Informative URLs:<br />
* http://forums.contribs.org/index.php?topic=35178.0 <br />
* http://forums.contribs.org/index.php?topic=31278.0<br />
* http://forums.contribs.org/index.php?topic=31279.0<br />
* http://forums.contribs.org/index.php?topic=32158.0<br />
* http://mirror.contribs.org/smeserver/contribs/michaelw/sme7/<br />
* http://mirror.contribs.org/smeserver/contribs/bread/mailstats/<br />
* http://wiki.apache.org/spamassassin/BayesInSpamAssassin<br />
* Enter this command at a console:<br />
perldoc Mail::SpamAssassin::Conf <br />
Last Updated ( Thursday, 21 June 2007 )<br />
<br />
===Email Clients===<br />
===="concurrency limit reached" when using IMAP====<br />
Sometime shows as Thunderbird giving this error message,<br />
''This Mail-server is not a imap4 mail-server''<br />
<br />
To workaround thunderbirds limitations change, this thunderbird setting to false<br />
* Preferences, Advanced, Config editor (aka about:config): filter on tls.<br />
* set security.enable_tls to false<br />
<br />
You can also increase the ConcurrencyLimitPerIP and/or ConcurrencyLimit value for imap and/or imaps (secure)<br />
config setprop imap ConcurrencyLimitPerIP 20<br />
config setprop imaps ConcurrencyLimitPerIP 20<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
check<br />
config show imap<br />
tail -f /var/log/imap/current | tai64nlocal<br />
<br />
More detail can be found [http://forums.contribs.org/index.php?topic=33124.0 here].<br />
<br />
====Mail server is not an IMAP4 mail server====<br />
This is a bug in Thunderbird, the previous tips may help<br />
<br />
====The Bat====<br />
The gives this error message, but they are wrong.<br><br />
"This server uses TLS v3.0 which is considered to be obsolete and insecure. <br />
The server must use TLS v3.1 or above."<br />
<br />
<br />
====Outlook/Outlook Express give error 10060/0x800CCC90====<br />
Most likely OUTLOOK (EXPRESS) isn't configured correctly.<br />
<br />
-open OUTLOOK<br />
-click TOOLS > ACCOUNTS<br />
-click CHANGE (on the right-hand side)<br />
-find INCOMING MAIL SERVER & OUTGOING MAIL SERVER (on right-hand side)<br />
-type: mail.yourdomain.tld (in both places)<br />
-click MORE SETTINGS (on bottom-right)<br />
-click OUTGOING SERVER tab (at the top)<br />
-checkmark "MY OUTGOING SERVER REQUIRES AUTHENTICATION"<br />
-bullet "USE SAME SETTINGS AS INCOMING MAIL SERVER"<br />
-click ADVANCED tab (at the top)<br />
-find OUTGOING SERVER<br />
-checkmark "THIS SERVER REQUIRES A SECURE CONNECTION" (under outgoing server)<br />
-change 25 to 465<br />
-[possibly required, secure IMAP is 993]<br />
-click OK > NEXT > FINISHED<br />
-you're finished, your email should work now<br />
<br />
====Outlook test message doesn't come through====<br />
You clicked the TEST ACCOUNT SETTINGS in OUTLOOK didn't you? This is a bug in OUTLOOK. The test message sends a test email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. To test, send an actual message from OUTLOOK.<br />
<br />
If you want, you can try THUNDERBIRD. It's like OUTLOOK but made by a different company. It's completely free and works very well at home and at the office.<br />
<br />
====I can't receive/send email from my application (ACT!, vTiger, MS Outlook, etc)====<br />
Most likely, this is a bug the application you're using and not a problem with the SMESERVER. The application sends an email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. <br />
<br />
As a workaround you can disable the check for the 'Date header'.<br />
To disable this check on the internal interface:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
To disable this check for the external interface: <br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
====After I upgrade my SME Server, my email folders have disappeared when using IMAP====<br />
After upgrade, if there are missing IMAP folders, the client may need to re-subscribe to folders. This may affect either webmail users or users who use an IMAP email client.<br />
<br />
====Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4====<br />
The main problem here is that Microsoft has decided that Entourage will only support trusted, PEM Base-64 Encoded certificates. To use IMAPS or SMTPS from Entourage with your SME server, you will need to:<br />
1. Login to your Mac as a user with administrative privileges<br />
<br />
2. Open Safari and browse to https://''smeserver''/server-manager. <br />
When you receive the warning about your certificate:<br />
- click on "Show Certificate"<br />
- click and drag the gold-rimmed image of a certificate to your desktop. <br />
You will now have ''myserver.mydomain.tld.cer'' on your desktop.<br />
<br />
3. Locate and open the '''Microsoft Cert Manager'''<br />
- "Import" the certificate you downloaded in step 2.<br />
<br />
4. Highlight the imported certificate and "Export" it. <br />
- Select the "PEM..." format<br />
- add "''pem.''" to the beginning of the filename<br />
- export it to your Desktop<br />
<br />
5. Double-click on the new ''pem.myserver.mydomain.tld.cer'' <br />
- Apple's '''Keychain Access''' application will open.<br />
- Select the '''X509Anchors''' Keychain and click "OK"<br />
<br />
6. While still in Apple's '''Keychain Access''', select the "Certificates" category<br />
- Drag ''pem.myserver.mydomain.tld.cer'' into the certificates window.<br />
<br />
You should now be able to connect to your SME from your Entourage using IMAPS. <br />
<br />
If you are accessing your SME server using a different name than the one encoded in the certificate you will still receive a security warning from Entourage, but "OK" will now grant access to your folders.<br />
<br />
Notes: <br />
* Procedure mostly taken from http://www.kerio.com/manual/kmsug/en/ch09s06.html<br />
* I still get various other IMAP errors due, I suspect, to the "concurrency limit reached" issue.<br />
* Click on "Show Keychains" in Apple's "Keychain Access" if you need to delete a certificate and try again.<br />
<br />
====How do I get my e-mail to show the correct From Address====<br />
<br />
The From address on an e-mail is not supplied by the server. It is supplied by the e-mail client.<br />
<br />
* Configure your Account in your e-mail client with the correct FROM address.<br />
* You can change the FROM address in webmail with the following:<br />
**Login to webmail as the user, go to ''options-personal information'' and change the ''identity'' to have the correct FROM address. You can have multiple identities with a single user.<br />
<br />
===Server Settings===<br />
====Double bounce messages====<br />
To stop admin receiving double bounce messages<br />
<br />
config setprop qmail DoubleBounceTo someoneuser<br />
signal-event email-update<br />
<br />
Or just delete them. You risk losing legitimate double bounces (which are<br />
rare, but you want to look at them when they do occur)<br />
<br />
config setprop qmail DoubleBounceTo devnull<br />
signal-event email-update<br />
<br />
see a longer explaination [[Email_delete_double-bounce_messages | here]]<br />
<br />
====Keep a copy of all emails====<br />
You may need to keep a copy of all emails sent to or from your email server.<br />
This may be for legal, or other reasons.<br />
<br />
The following instructions will create a new user account (maillog) and forward every email that goes through your SME server to it.<br />
<br />
First, log onto the server-manager and create the user '''maillog'''<br />
<br />
Go to the SME Command Line (logon as root) and issue the following commands:<br />
<br />
config setprop qpsmtpd Bcc enabled<br />
signal-event email-update<br />
<br />
Optionally make the forwarding of the emails invisible to the end user. Without it, there will be an X-Copied-To: header in each email. Run this command before the signal-event<br />
<br />
config setprop qpsmtpd BccMode bcc<br />
<br />
If you want to view the emails, point your email client at the SME and log on as maillog.<br />
<br />
====Set max email size====<br />
There are several components involved in sending email on a SME server. Each component has a size limit that may affect an email message that passes through the server.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
! Subsystem<br />
! Function<br />
! Default Limit<br />
! Command to change size<br />
! Notes<br />
|-<br />
|qmail<br />
|Delivers email to local mailboxes and to remote servers<br />
|15000000<br />
|config&nbsp;setprop&nbsp;qmail&nbsp;MaxMessageSize&nbsp;xx000000<br />
|Value is in BYTES. 15000000 equals approximately 15MB<br />
|-<br />
|clamav<br />
|Used to scan emails and attachments<br />
|15M<br />
|config&nbsp;setprop&nbsp;clamav&nbsp;MaxFileSize&nbsp;15M<br />
|value includes human-readable abbreviations. "15M" equlas 15 MegaBytes.<br />
|-<br />
|qpsmtpd<br />
|The clamav plugin to qpsmtpd is called with a specified size limit.<br />
|25000000<br />
|config&nbsp;setprop&nbsp;qpsmtpd&nbsp;MaxScannerSize&nbsp;xx000000<br />
|Value is in BYTES.<br>Question: does this value override the setting of 'MaxFileSize', or will the smaller value prevail?<br />
|-<br />
|php<br />
|The php maximum file upload size will determine the largest file you can attach to an email message using horde (or any other php email client)<br />
|10M<br />
|config&nbsp;setprop&nbsp;php&nbsp;UploadMaxFilesize&nbsp;10M<br />
|<br />
|-<br />
|}<br />
A note about clamav:<br><br />
ClamAV includes settings to prevent the scanning of archives that could cause problems if fully expanded; if an attachment cannot be scanned, it will be rejected.<br />
<br />
These attributes could result in the rejection of a compressed attachment on a SME server:<br />
* ArchiveMaxCompressionRatio (default 300)<br />
* MaxFiles (default 1500)<br />
* MaxRecursion (default 8)<br />
<br />
====Add the admin user as an administrator for Horde====<br />
<br />
config setprop horde Administration enabled <br />
signal-event email-update<br />
<br />
==== Large attachments not displaying in webmail ====<br />
Due to limits set in the PHP configuration it might be that webmail will not display large attachments (see also [[bugzilla:3990]]). The following entries are related to the error and can be found in the log files:<br />
<br />
'''/var/log/messages'''<br />
Mar 13 00:00:12 box1 httpd: PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 154 bytes) in /home/httpd/html/horde/imp/lib/MIME/Contents.php on line 173<br />
<br />
'''/var/log/httpd/error_log'''<br />
Allowed memory size of 33554432 bytes exhausted (tried to allocate 0 bytes)<br />
<br />
The default MemoryLimit setting in PHP is set to 32M the value can be changed using the commands below replacing ''XX'' with the value you desire.<br />
{{Note box|You can set the MemoryLimit any value you like but be sure to add the capital M as a suffix for Megabytes.}}<br />
db configuration setprop php MemoryLimit XXM<br />
expand-template /etc/php.ini<br />
sv t httpd-e-smith<br />
<br />
====Disable mail to a user from an external network====<br />
Can be either a user, pseudonym or group<br />
db accounts setprop groupname/username Visible internal<br />
signal-event email-update<br />
<br />
====I can't receive mail at: user@mail.domain.tld====<br />
Add mail.domain.tld as a virtualdomain.<br />
-login to SERVER-MANAGER<br />
-click DOMAINS (on the left)<br />
-click ADD<br />
-type: mail.domain.tld<br />
<br />
====How do I find out who is logged into webmail and what IP number.====<br />
This is logged is in /var/log/messages.<br />
<br />
====How do I enable smtp authentication for users on the internal network.====<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cp /etc/e-smith/templates/var/service/qpsmtpd/config/peers/0/05auth_cvm_unix_local .<br />
signal-event email-update<br />
(note the "." at the end of the 3rd line)<br><br />
Authentication for the local network will now follow the setting of config::qpsmtpd::Authentication<br />
<br />
====How do I disable SMTP relay for unauthenticated LAN clients====<br />
http://forums.contribs.org/index.php?topic=38797.msg176490#msg176490<br />
* Enable smtp authentication as shown above<br />
* Disable un-authenticated smtp relay for the local network(s)using:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients<br />
echo "# SMTP Relay from local network denied by custom template" >\<br />
/etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients/80relayFromLocalNetwork<br />
signal-event email-update<br />
<br />
* Configure your email clients to use smtps with authentication:<br><br />
- change outgoing smtp port to 465 and select SSL<br><br />
- enable Authentication against the outgoing mail server<br />
<br />
<br />
====Internet provider's port 25 is blocked: How to set an alternative port for the SMTP server====<br />
If your provider is blocking smtp port 25 on your internet connection but your hosting provider is offering an alternative port (or when using some relay service) you can simply set this alternative port by adding it to the 'Address of Internet provider's mail server' value in the 'E-mail delivery settings' screen of the server-manager like this:<br />
<internet providers mail server name or ip-address>:<alternative port><br />
For example: mail.mydomain.com:587<br />
<br />
====How do I enable and configure a disclaimer in email messages====<br />
<br />
<br />
A disclaimer message can be added to the footer of all outgoing email messages.<br />
<br />
The message can be the same for all domains or it can be different for all domains.<br />
<br />
This functionality is part of sme7.2 release so make sure you have upgraded before doing this.<br />
<br />
To create a general disclaimer for all domains on your sme server<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer<br />
Enter the required disclaimer text <br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
To make the changes take effect<br />
signal-event email-update<br />
<br />
<br />
To create domain specific disclaimers, create seperate domain based disclaimer text files<br />
<br />
Delete the general (all domains) disclaimer file if you have already created it<br />
rm /service/qpsmtpd/config/disclaimer<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer_domain1.com.au<br />
pico -w /service/qpsmtpd/config/disclaimer_domain2.com<br />
pico -w /service/qpsmtpd/config/disclaimer_domain3.org<br />
<br />
Enter the required text in each disclaimer file<br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
After making any changes remember to do<br />
signal-event email-update<br />
<br />
<br />
Note if you only wish to have a disclaimer for some domains, then only create a disclaimer text file for those domains <br />
<br />
<br />
Note also the criteria for when a disclaimer is attached <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648)<br />
<br />
eg a disclaimer is added to internal to external messages but not internal to internal messages.<br />
<br />
There are also various switches that can be applied <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648).<br />
<br />
<br />
To disable the disclaimer function for all domains on your sme server<br />
config setprop smtpd disclaimer disabled<br />
signal-event email-update<br />
<br />
<br />
====Email WBL server manager panel====<br />
<br />
There is a server manager contrib to allow GUI control of email white and black lists.<br />
<br />
The panel allows easy configuration of functionality that is built into qmail, qpsmtpd and spamassassin. For more information google for qmail & qpsmtpd, read the spamassassin section in this wiki article and see [http://wiki.contribs.org/Email#Default_Plugin_Configuration default qpsmtpd plugin confguration]).<br />
<br />
{{Warning box|It is a test release, although it has been in use since Jan 2007 and appears functionaly stable. To install do:<br />
wget http://mirror.contribs.org/smeserver/contribs/dmay/smeserver/7.x/testing/smeserver-wbl/smeserver-wbl-0.0.1-a8.dmay.noarch.rpm <br />
rpm -Uvh smeserver-wbl*.rpm<br />
}}<br />
<br />
There are two main sections, Reject and Accept, where you can control settings.<br />
<br />
Reject - Black lists are used for rejecting e-mail traffic<br />
<br />
DNSBL status - DNSBL is an abbreviation for "DNS blacklist". <br />
It is a list of IP addresses known to be spammers.<br />
RHSBL status - RHSBL is an abbreviation for "Right Hand Side Blacklist". <br />
It is a list of domain names known to be spammers.<br />
qpsmtpd badhelo - Check a HELO message delivered from a connecting host. <br />
Reject any that appear in badhelo during the 'helo' stage.<br />
qmail badmailfrom - Check envelope sender addresses. <br />
Reject any that appear (@host or user@host) in badmailfrom during the 'mail' <br />
stage.<br />
<br />
Accept - White lists are used for accepting e-mail traffic<br />
<br />
Whitelists status - White Lists: ACCEPT<br />
qpsmtpd whitelisthosts - Any IP address listed in whitelisthosts will be exempted <br />
from any further validation during the 'connect' stage.<br />
qpsmtpd whitelisthelo - Any host that issues a HELO matching an entry in whitelisthelo <br />
will be exempted from further validation during the 'helo' stage.<br />
qpsmtpd whitelistsenders - Any envelope sender of a mail (@host or user@host) matching an <br />
entry in whitelistsenders will be exempted from further validation<br />
during the 'mail' stage.<br />
spamassassin whitelist_from - Any envelope sender of a mail (*@host or user@host) matching an <br />
entry in whitelist_from will be exempted from spamassassin rejection.<br />
<br />
<br />
After making any changes using this panel you must click both the Save and Update buttons, in order for changes to take effect.<br />
<br />
===External Access===<br />
====Allow external IMAP mail access====<br />
There was a deliberate decision to remove non-SSL protected username/password<br />
services from the external interface.<br />
<br />
to allow unsecure IMAP access<br />
<br />
config setprop imap access public<br />
signal-event email-update<br />
<br />
But before you do this try to use secure IMAP<br><br />
fixme: explain how<br />
<br />
====POP3 & webmail HTTP====<br />
I want to set my SMESERVER to allow POP3 (or webmail HTTP) but it's not an option, I only see POP3S (or webmail HTTPS).<br />
<br />
The SMESERVER is secure by design. POP3 (or webmail HTTP) is viewed as inadequate security and removed as an option from a standard installation to encourage unknowing administrators to select the 'best practice' option -a secure connection with POP3S, IMAPS, or HTTPS.<br />
<br />
You can still set your SMESERVER to allow POP3 settings by:<br />
config setprop pop3 access public<br />
signal-event email-update<br />
<br />
====Allow external pop3 access====<br />
<br />
Email settings > POP3 server access in SME 7.1 server-manager allows only pop3s protocol for clients outside the LAN. Some email clients (eg The Bat! v3.98.4) won't allow pop3s connections to SME 7.1 because of ssl version conflict. Until this is sorted out, a workaround is to hack SME to allow regular pop3 on the external interface using the following commands. <br />
<br />
config setprop pop3 access public<br />
signal-event email-update<br />
svc -t /service/pop3s <br />
<br />
more information [[bugzilla:2620]]<br />
<br />
===Imap===<br />
====Folders with a dot in name====<br />
Email folder names that have a period ('.') in the folder name, will be split into sub-folders.<br />
e.g. folder name 'www.contribs.org' is created as<br />
www<br />
contribs<br />
org<br />
<br />
===qpsmtpd===<br />
SME uses the [http://smtpd.develooper.com qpsmtpd] smtp daemon.<br />
<br />
====Official Description====<br />
qpsmtpd is a flexible smtpd daemon written in Perl. Apart from the core SMTP features, all functionality is implemented in small "extension plugins" using the easy to use object oriented plugin API.<br />
<br />
qpsmtpd was originally written as a drop-in qmail-smtpd replacement, but now it also includes smtp forward, postfix, exim and maildir "backends".<br />
<br />
qpsmtpd wiki: http://wiki.qpsmtpd.org <br />
<br />
<br />
====Default Plugin Configuration====<br />
SME uses the following [http://wiki.qpsmtpd.org/plugins qpsmtpd plugins] to evaluate each incoming email. <br />
<br />
SME maintains 2 distinct configurations: one for the 'local' networks (as defined in server-manager::Security::Local networks) and another for 'remote' networks (everyone else).<br />
<br />
The default configuration of each plugin is indicated in the 'Default Status' column.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
!Plugin<br />
!Purpose<br />
!Default Status<br />
|-<br />
|hosts_allow<br />
|Prohibit more than "InstancesPerIP" connections from any single host (change with 'config setprop smtp InstancesPerIP'). Allow or deny connections according to the contents of /var/service/qpsmtpd/config/hosts_allow. See [http://svn.perl.org/qpsmtpd/trunk/plugins/hosts_allow hosts_allow SVN code] for more details.<br />
|[http://bugs.contribs.org/show_bug.cgi?id=3352 upcoming]<br />
|-<br />
|peers<br />
|Allow different plugin configuration based on the sending computer's IP address. By default SME maintains different configurations for the local networks (in /var/service/qpsmtpd/config/peers/local) and for everyone else (in /var/service/qpsmtpd/config/peers/0)<br />
|enabled<br />
|-<br />
|logging/logterse<br />
|Allow greater logging detail using smaller log files<br />
|enabled<br />
|-<br />
|auth/auth_cvm_unix_local<br />
|Allow authenticated smtp relay<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_earlytalker<br />
|reject email from servers that talk out of turn<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|count_unrecognized_commands<br />
|reject email from servers that issue ''X'' invalid commands<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|bcc<br />
|bcc all email to a specific address for archiving<br />
|'''disabled'''<br />
|-<br />
|check_relay<br />
|Check to see if relaying is allowed (in case the recipient is not listed in one of SME's local domains)<br />
|enabled<br />
|-<br />
|check_norelay<br />
|Check to see if the sending server is specifically forbidden to relay through us.<br />
|enabled<br />
|-<br />
|require_resolvable_fromhost<br />
|Check that the domain listed in the sender's email address is resolvable<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_basicheaders<br />
|reject email that lacks either a From: or Date: header<br />
|enabled<br />
|-<br />
|rhsbl<br />
|Reject email if the sender's email domain has a reputation for disregarding smtp RFCs.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|dnsbl<br />
|Reject email from hosts listed in your configured dnsbl servers<br />
|'''disabled'''<br />
|-<br />
|check_badmailfrom<br />
|Reject email where the sender address is listed in /var/service/qpsmtpd/config/badmailfrom<br />
|enabled<br />
|-<br />
|check_badrcptto_patterns<br />
|Reject email addressed to any address matching an expression listed in /var/service/qpsmtpd/config/badrcptto_patterns<br />
|enabled<br />
|-<br />
|check_badrcptto<br />
|Reject email addressed to any address listed in /var/service/qpsmtpd/config/badrcptto<br />
|enabled<br />
|-<br />
|check_spamhelo<br />
|Reject email from hosts that say 'helo ...' using a value in /var/service/qpsmtpd/config/badhelo<br />
|enabled<br />
|-<br />
|check_smtp_forward<br />
|If ''config show DelegateMailServer'' or ''db domains show <domainname> MailServer'' is set (telling SME to deliver email for all domains or just <domainname> to another server), check_smtp_forward will connect to the specified server and will reject the message outright if the internal mail server would also reject it.<br />
|'''disabled'''<br>unless an internal mail server is configured.<br />
|-<br />
|check_goodrcptto<br />
|Accept email only if the recipient address matches an entry in /var/service/qpsmtpd/config/goodrcptto. For domains that are configured to use an internal mail server, the entire domain name will be added to .../goodrcptto.<br />
|enabled<br />
|-<br />
|rcpt_ok<br />
|Return 'OK' if none of the other host checks has returned 'DENY' (??)<br />
|enabled<br />
|-<br />
|pattern_filter<br />
|Reject email according to content patterns (??)<br />
|'''disabled'''<br />
|-<br />
|tnef2mime<br />
|Convert MS TNEF (winmail.dat) and uuencoded attachments to MIME<br />
|enabled<br />
|-<br />
|disclaimer<br />
|Add a configurable disclaimer to email messages<br />
|'''disabled'''<br />
|-<br />
|spamassassin<br />
|Check email using spamassassin, and optionally reject it completely if the score exceeds a configurable value.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|virus/clamav <br />
|Scan incoming email with ClamAV<br />
|enabled<br />
|-<br />
|queue/qmail-queue<br />
|Deliver the incoming message to qmail for delivery.<br />
|enabled<br />
|-<br />
|}<br />
<br />
===Internal Mail Servers===<br />
SME can be configured as a spam and antivirus filter for one or more "Internal" mail servers on a domain-by-domain basis. The mail server specified does not have to be on the same local network as your SME server.<br />
<br />
====Deliver ALL email to a single internal mail server====<br />
You can deliver all email for all domains on your SME server to a single internal mail server by setting the mail server address in server-manager::Configuration::E-mail::Change e-mail delivery settings::Address of internal mail server.<br />
<br />
====Deliver email for one domain to an internal mail server====<br />
You can also configure only a single domain to use an internal mail server, or you can configure different domains to use different internal mail servers.<br />
<br />
First, create the necessary virtual domains using server-manager::Configuration::Domains::Add Domain.<br />
<br />
Then, (assuming your domain is called ''test.com'' and the actual mail server is at ''a.b.c.d'' issue the following commands:<br />
db domains setprop test.com MailServer a.b.c.d<br />
signal-event email-update<br />
<br />
=== Secondary/Backup Mail Server Considerations ===<br />
<br />
Many people misunderstand the issues of using a secondary or backup <br />
mail server (backup MX) to hold your mail before it gets delivered <br />
to your SME Server. If you consider putting a backup mail server in <br />
place because you are concerned about lost mail because your internet<br />
connection may occasionally drop out, think again and consider the issues<br />
discussed below.<br />
<br />
====What is ''Backup MX''====<br />
<br />
A backup MX is a system whereby through your DNS records you tell other<br />
servers on the internet that in order to deliver mail to your domain they<br />
first need to try the primary MX record and if they fail to connect they<br />
can try to connect to one or more of your listed backup or secondary mail <br />
servers. See also http://en.wikipedia.org/wiki/MX_record<br />
<br />
====The process of delivering email to your SME Server====<br />
<br />
So lets look at how mail gets delivered without and with a <br />
''backup mx'' when your Internet link, ISP or server is down.<br />
<br />
====='''Without''' a backup MX=====<br />
<br />
* The sending mail server cannot connect to your server.<br />
* The sending mail server MUST queue the mail and try again later.<br />
* The mail stays on the sender's server.<br />
* The sender's server resends the mail at a later date.<br />
<br />
''The requirement to re-queue is a fundamental part of the SMTP protocol - <br />
it is not optional. So, if your server is '''offline''' due to a link or ISP <br />
outage, '''the mail just stays at the sender's server until you are once <br />
again reachable'''.<br />
<br />
====='''With''' a backup MX=====<br />
<br />
* The sending mail server cannot contact your server.<br />
* The sending mail server sends the mail to your secondary MX.<br />
* The secondary MX queues the mail until your link/server is up.<br />
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'').<br />
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs.<br />
* You have no, or little, visibility over the queued mail.<br />
* When your link comes up, the secondary MX sends the mail on to your server.<br />
* You have added more hops, more systems and more delay to the process.<br />
<br />
If you think that a backup MX will protect against broken mail servers <br />
which don't re-queue, you can't. Those servers will drop mail on the floor<br />
at random times, for example when ''their'' Internet link is down. <br />
<br />
Those servers are also highly likely to never try your backup MX. <br />
<br />
Thankfully those servers are mostly gone from the Internet, but adding a <br />
secondary MX doesn't really improve the chances that they won't drop mail<br />
destined for your server on the floor.<br />
<br />
====Backup MX and SPAM Filtering====<br />
<br />
On top of the issue, indicated above, there is another issue to consider<br />
and that is what happens with SPAM due to the use of a ''Backup MX''. <br />
<br />
Your SME Server takes care of filtering a lot of SPAM by checking on the full <br />
username & domain at the time it is received.<br />
<br />
For example if your server hosts '''example.com''' and someone sends <br />
mail to '''joeuser@example.com''', the server will '''only''' accept the mail<br />
if joeuser is a local user/alias/group/pseudonym on the server. <br />
Otherwise, the mail is rejected during the SMTP transaction.<br />
<br />
A backup mail server however, generally does not have a full list of<br />
users against which it can check if it should accept the mail for the given<br />
domain. Hence it will accept mail for ''invalid'' users.<br />
<br />
So:<br />
<br />
* If you trust the secondary MX, you <u>will</u> accept a lot of SPAM when the link comes up.<br />
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.<br />
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.<br />
<br />
The SPAM backscatter can only be stopped if the secondary MX has a full list<br />
of users for your domain to allow filtering to occur.<br />
<br />
But:<br />
<br />
* You need to be able to configure this secondary MX with such user/domain lists<br />
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration<br />
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.<br />
<br />
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find <br />
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail. <br />
<br />
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.<br />
<br />
* If you bounce mail at your server, you have logs to show what's wrong. <br />
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.<br />
<br />
==== Summary ====<br />
<br />
In summary, if your server/Internet connection is available most (let's say >90%) of <br />
the time, you are generally better off <u>without a secondary MX</u>. <br />
<br />
If your server/link is down more than this (e.g. dialup), you should not be delivering mail <br />
directly to your server.<br />
<br />
If you still want to consider setting up a seconday MX, ensure that:<br />
<br />
* you have fully control of the configuration of each of the email gateways for your domain<br />
* each gateway can make decisions on whether to accept/reject mail for the users at the domain<br />
<br />
===User accounts===<br />
====Multiple users with the same name on different domains====<br />
''The Manuel contains a detailed explanation here [http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter9#Pseudonyms], however, this question is frequently asked in the forums and this FAQ was added in response to this thread [http://forums.contribs.org/index.php?topic=41558.0;all]''<br />
<br />
SME only supports one name set, so you cannot have multiple user accounts for the same user (eg joe) at different domains, you can only have one user account for joe which applies to all domains.<br />
<br />
The workaround is to create user accounts with a different name to what will be used as an email address.<br />
<br />
eg.<br />
*create user account joe1<br />
*create user account joe2<br />
*create user account joe3<br />
<br />
'''DO NOT create a user account for joe'''<br />
<br />
*create pseudonym for joe@domain1 which forwards to user account joe1<br />
*create pseudonym for joe@domain2 which forwards to user account joe2<br />
*create pseudonym for joe@domain3 which forwards to user account joe3<br />
<br />
joe1 logs in using joe1 but advertises their email address as joe@domain1<br />
<br />
Your main or primary domain is created during initial setup in the admin console, Configure this server. <br />
Your additional domains are created using the Domains panel, and are called Virtual domains, but they function virtually identically to the main domain. In the Domains panel, you select an ibay for the content that will apply to virtual domain web sites.<br />
<br />
<br />
The mail server accepts mail for all valid domains (either the main or virtual), and delivers the mail to end user acounts or pseudonym addresses.<br />
<br />
Note you do not need to use pseudonyms.<br />
<br />
You can just do the following.<br />
*create user account joe1 with effective email address of joe1@domain1<br />
*create user account joe2 with effective email address of joe2@domain2<br />
*create user account joe3 with effective email address of joe3@domain3<br />
<br />
This arrangement will work fine, but note that if email is inadvertantly sent to joe2@domain1 then joe2 will still receive that email (rather than joe1).<br />
External users would not really be sending to joe2@domain1 as that address has never been advised to anyone as being active.<br />
<br />
<noinclude>[[Category:Howto]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10180
Netkeeper Remote Server Monitor
2008-06-27T13:55:18Z
<p>Mercyh: /* Installation */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
**''Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Upgrading from v0.2 to v0.3===<br />
* Version 0.3 shows the date and time of the last successful Affa backup job instead of just ''SUCCESS'' or ''FAILURE''.<br />
<br />
# Download ''NRSM_Update_v0.2_to_v0.3.zip''<br />
# Unzip and replace the old NRSM.exe with the new one.<br />
# Download and replace ''post.pl'' on the servers with Affa backup monitoring.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10155
Netkeeper Remote Server Monitor
2008-06-25T20:43:30Z
<p>Mercyh: /* Installation */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
**''Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10154
Netkeeper Remote Server Monitor
2008-06-25T20:37:51Z
<p>Mercyh: /* Installation */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
''**Make sure the raid status is correct and raid is in sync before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10153
Netkeeper Remote Server Monitor
2008-06-25T20:33:40Z
<p>Mercyh: /* Installation */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
''**Make sure the raid status is correct before accepting. This is considered the baseline and is stored in the Server's database in NRSM. Once this is accepted, all future raid status checks will be against this baseline and any change in status will be shown as FAILURE.''<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Email&diff=10146
Email
2008-06-23T20:56:02Z
<p>Mercyh: /* How do I get my e-mail to show the correct From Address */</p>
<hr />
<div>==Email==<br />
===Spam===<br />
====Spamassassin====<br />
Set spamassassin for automatically delete junkmail.<br />
You can change the "days" that spamassassin sets to automatically delete junkmail, to delete after two months <br />
<br />
db configuration setprop spamassassin MessageRetentionTime 60 <br />
signal-event email-update <br />
<br />
<br />
The "Custom spam rejection level" will only work when "Spam sensitivity" is set to custom.<br />
<ol></li><li>Open server-manager.<br />
</li><li>Click e-mail in the navigation pane (left-hand side).<br />
</li><li>Click Change e-mail filtering settings.<br />
</li><li>Change "Spam sensitivity" to custom and adjust the settings to your liking.<br />
</li></ol><br />
<br />
This happens because by default, no mail (except for viruses) gets rejected without the admin doing something first.<br />
<br />
====='''X-Spam-Level Header in Email Messages'''=====<br />
SME does not create an X-Spam-Level header in processed email messages by default.<br />
<br />
To enable this capability:<br />
/usr/bin/yum install --enablerepo=smecontribs smeserver-qpsmtpd-spamassassinlevelstars<br />
signal-event email-update<br />
<br />
(Based on [[Bugzilla:3505]])<br />
<br />
=====Custom Rule Scores=====<br />
You can customize the score assigned by a specific Spamassassin rule (SARE_ADULT2 in this case) as follows:<br />
mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
echo "score SARE_ADULT2 20.000" >> 20localscores<br />
signal-event email-update<br />
<br />
You can now add additional tests and custom scores by editing the newly-created template fragment ''20localscores'' and adding new custom scores using:<br />
pico -w /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
Each custom score goes on its own line. If you enter a score surrounded by parentheses, the "custom" score will be added to the default score for the specified test (use ''score TEST_NAME (-1)'' to reduce the score for 'TEST_NAME' by 1) <br />
<br />
You can remove these customizations using: <br />
rm -f /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
<br />
References:<br />
* http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#scoring_options<br />
* http://spamassassin.apache.org/tests_3_2_x.html<br />
* http://www.rulesemporium.com/<br />
<br />
====Real-time Blackhole List (RBL)====<br />
Enabling RBL's <br><br />
RBL's are disabled by default to allow maximum accommodation (your ISP may be on a RBL & you may not know it). You can enable RBL's by:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
signal-event email-update<br />
<br />
You can see your RBL's by:<br />
config show qpsmtpd<br />
<br />
You can add to your RBL's by:<br />
config setprop qpsmtpd RBLList <rbl-list-name><br />
signal-event email-update<br />
<br />
Many will argue what's best but most would agree that you can set best-practice recommended settings by:<br />
config setprop qpsmtpd RBLList zen.spamhaus.org:whois.rfc-ignorant.org:dnsbl.njabl.org<br />
signal-event email-update<br />
<br />
Note: More information on this topic can be found here:<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#RHSBL_Servers]<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#DNSBL_Servers]<br />
<br />
====Server Only====<br />
Some of the spam filter rules cannot work unless the SMESERVER knows the external IP of the box. If you put a SMESERVER in server-only mode behind other firewalls, it will lose some of the anti-spam rules. For example, the rule that blocks attempts where spammers try "HELO a.b.c.d" where a.b.c.d is your external IP address.<br />
<br />
Unfortunately, many admins believe that port-forwarding SMTP provides additional security. It doesn't, it limits the SMESERVER's ability to apply some rules.<br />
<br />
<br />
====I want to enable GreyListing====<br />
GreyListing support is under the covers and can easily be enabled for those who know what they are doing. However, many experienced users found that they spent more time looking after the greylisting configuration than they received in benefit.<br />
<br />
====Setup Blacklists & Bayesian Autolearning====<br />
<br />
(Much of what follows has been shamelessly copied from the Sonoracomm howto)<br />
<br />
The default SME settings (as you can see [http://wiki.contribs.org/Email#Default_Plugin_Configuration here]) do not include DNSBL filtering, spam rejection, or (which is not obvious from the above) bayesian filtering in spamassassin to allow spamassassin to learn from received email and improve over time.<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set<br />
thresholds for the bayesian filter.<br />
<br />
config setprop spamassassin UseBayes 1<br />
config setprop spamassassin BayesAutoLearnThresholdSpam 4.00<br />
config setprop spamassassin BayesAutoLearnThresholdNonspam 0.10<br />
expand-template /etc/mail/spamassassin/local.cf<br />
sa-learn --sync --dbpath /var/spool/spamd/.spamassassin -u spamd<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes_*<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes.mutex<br />
chmod 640 /var/spool/spamd/.spamassassin/bayes_* <br />
config setprop qpsmtpd DNSBL enabled<br />
config setprop qpsmtpd RHSBL enabled<br />
config setprop spamassassin status enabled<br />
config setprop spamassassin RejectLevel 12<br />
config setprop spamassassin TagLevel 4<br />
config setprop spamassassin Sensitivity custom<br />
signal-event email-update<br />
<br />
These commands will:<br />
* enable spamassassin<br />
* configure spamassassin to reject any email with a score above 12<br />
* tag spam scored between 4 and 12 in the email header<br />
* enable bayesian filter<br />
* 'autolearn' as SPAM any email with a score above 4.00<br />
* 'autolearn' as HAM any email with a score below 0.10<br />
* enable RHSBL using the default SBLList. Note that rhsbl checking has been known to place a heavy burden on SME servers.<br />
* enable DNSBL using the default RBLList<br />
<br />
====The entire Sonoracomm howto from Google's text cache====<br />
* The Sonoracomm HowTo has been a very well regarded set of instructions for SME mail server configuration for quite a while.<br />
<br />
* This section was created during an extended outage of the Sonoracomm web server (in 2007?)<br />
<br />
* The Sonoracomm HowTo has been updated since this section was created, and is well worth examining. View the current version at: http://www.sonoracomm.com/index.php?option=com_content&task=view&id=49&Itemid=32<br />
<br />
* The content below has been modified to include changes suggested in the bug tracker and forums.<br />
<br />
* These instructions are aimed mostly at configuring SME as the only mail server, not for using SME with an internal mail server. (Specifically, LearnAsSpam.pl is harder to configure when using an internal mail server - you would have to develop a method for getting the unmarked SPAM into an IMAP folder directly on the SME server itself. Not impossible, but difficult!)<br />
<br />
'''SONORA COMMUNICATIONS, INC.'''<br />
<br />
This is a quick configuration howto, not an in-depth look at SpamAssassin. Much more can be done<br />
beyond this document, but this will take a big dent out of your spam and free up CPU cycles on your server.<br />
<br />
See 'More Information' at the end.<br />
<br />
'''SpamAssassin'''<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set thresholds for the bayesian filter.<br />
<nowiki>rpm -Uvh \<br />
http://mirror.contribs.org/smeserver/contribs/\<br />
michaelw/sme7/smeserver-spamassassin-features-0.0.2-0.noarch.rpm</nowiki><br />
<br />
This command will install the FuzzyOCR SA plugin designed to catch those nasty image-based spam messages.<br />
yum -y --enablerepo=smeupdates-testing install FuzzyOcr<br />
<br />
'''Server-Manager'''<br />
<br />
Using the Server-Manager Configuration/E-Mail panel, adjust the settings to these reasonable <br />
* Virus scanning Enabled<br />
* Spam filtering Enabled<br />
* Spam sensitivity Custom<br />
* Custom spam tagging level 4<br />
* Custom spam rejection level 12<br />
* Sort spam into junkmail folder Enabled<br />
* Modify subject of spam messages Enabled<br />
<br />
It is also recommend blocking all executable content. To do so, select (highlight) all of the attachment types other than zip files (the last two).<br />
<br />
Click Save.<br />
<br />
'''How It Works'''<br />
<br />
When receiving an incoming message, the server first tests for RBL and DNSBL listings, if enabled. If the sender is blacklisted, the messages are blocked outright and Spamassassin never sees it. <br />
<br />
With this configuration, the spammiest messages, those marked as 12 or above, will be rejected at the SMTP level. Those spam messages marked between 4 and 12, will be routed to the users' (IMAP) junkmail folder. This is done so the users can check for false-positives...valid messages that were classified as spam by SpamAssassin.<br />
<br />
Users may check their junkmail folders for false-positives via webmail, or, if they are using an IMAP mail client, by simply checking the junkmail folder exposed by their mail client.<br />
<br />
https://servername/webmail<br />
<br />
'''Tweaking'''<br />
<br />
The server will automatically delete old spam in the junkmail folders after 90 days. You can control the number of days old spam is kept with the following commands. Where 15 is the number of days you want to keep messages, do...<br />
<br />
db configuration setprop spamassassin MessageRetentionTime 15<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
then<br />
<br />
config show spamassassin<br />
<br />
If you think you are losing misclassified mail, adjust the ''Custom spam rejection level'' higher.<br />
<br />
If too much spam is making through to your inbox, carefully adjust the 'Custom spam tagging level' down. Many people use the level 4. Anything below that may result in false-positives. YMMV.<br />
<br />
If too much spam is building up in your (IMAP) junkmail folder, adjust the 'Custom spam rejection level' down or change the number of days spam is kept in the junkmail folder before being automatically deleted by the server.<br />
<br />
'''Bayesian (Learning) Filter'''<br />
<br />
Install the LearnAsSpam.pl, (optional) mailstats and sa-update scripts, then configure nightly cron jobs like this:<br />
<nowiki>cd /usr/bin<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.pl<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/spamfilter-stats-7.pl<br />
cd /etc/cron.d<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.cron<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/mailstats.cron<br />
cd /etc/cron.daily<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/sa-update<br />
chmod +x sa-update<br />
/etc/rc.d/init.d/crond restart</nowiki><br />
<br />
Using an IMAP mail client, create a new folder called 'LearnAsSpam' (case sensitive). It can be created at the top level (like 'Inbox') or as a sub-folder. Create the folder for each user that will help train the Bayesian filter. Webmail will work fine for creating this folder, as well as for checking the junkmail (filtered mail or quarantine) folder.<br />
<br />
If any spam messages make it past the filter and into your inbox, just move them into the LearnAsSpam folder. A nightly cron job will process them and delete them for you. This is how you train the Bayesian filter.<br />
<br />
'''Testing'''<br />
<br />
You can check the auto-learning statistics with this command. You will be able to note the accumulation of the spam tokens (or not). Note that the Bayesian filtering must receive 200 spam messages before it starts to function, so don't expect instantaneous results.<br />
sa-learn --dump magic<br />
<br />
You can check the spam filter log with this command: <br />
tail -50 /var/log/spamd/current | tai64nlocal<br />
<br />
If you ever see an error such as:<br />
''warn: bayes: cannot open bayes databases /etc/mail/spamassassin/bayes_* R/W: tie failed: Permission denied''<br />
Try adjusting some permissions with these commands:<br />
chown :spamd /var/spool/spamd/.spamassassin/*<br />
chmod g+rw /var/spool/spamd/.spamassassin/* <br />
<br />
'''Whitelist and Blacklist'''<br />
<br />
If mail comes in and it is misclassified as spam (and moved to the junkmail folder when that feature is enabled), you can add the sender to the whitelist so that future messages coming in from that sender are not filtered.<br />
<br />
Conversely, you can add a spammer to the blacklist so you never see their spam again. <br />
<br />
Add senders (or their entire domains) to the global whitelist (or blacklist) with commands similar to these (as root):<br />
db spamassassin setprop wbl.global *@vonage.com White<br />
db spamassassin setprop wbl.global *domain2.com White<br />
db spamassassin setprop wbl.global badname@baddomain.com Black<br />
db spamassassin setprop wbl.global *@verybaddomain.com Black<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it White<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can enter multiple addresses/domains for both white and black lists in one command<br />
db spamassassin setprop wbl.global name@domain.com White *domain2.com White *domain3.com Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can view the lists with this command:<br />
db spamassassin show<br />
<br />
You can delete one or more entries from the white/blacklist using<br />
db spamassassin delprop wbl.global name@domain.com *domain2.com<br />
* name@domain.com and *domain2.com must exactly match a value in the output from ''db spamassassin show'' to the ''left'' of the equals sign. <br />
* You do not need to specify ''White'' or ''Black'' when deleting entries.<br />
<br />
<br />
<br />
'''Clam Antivirus'''<br />
<br />
Update and check your Clam Antivirus with this command. This is normally done automatically every hour via cron.<br />
freshclam -v<br />
<br />
or<br />
freshclam --debug<br />
<br />
Verify hourly update checking by viewing the freshclam/current log file via the Server-Manager View Log Files panel.<br />
<br />
'''Realtime Blackhole Lists and DNS Blacklists'''<br />
<br />
To view the settings for the RBL and DNSBL, use this command:<br />
config show qpsmtpd<br />
<br />
If you followed the instructions above, both checks are enabled.<br />
<br />
To see the log of these tests, use a command like:<br />
tail /var/log/qpsmtpd/current | tai64nlocal <br />
<br />
To specify multiple RBLs, use a command like this:<br />
config setprop qpsmtpd RBLList \<br />
bl.spamcop.net,combined.njabl.org,dnsbl.ahbl.org,dnsbl-1.uceprotect.net,\<br />
list.dsbl.org,multihop.dsbl.org,psbl.surriel.com,zen.spamhaus.org<br />
<br />
Note: we have had trouble with the uceprotect.net level 2 list and sometimes remove it from the list as shown here.<br />
<br />
To enable or disable both available lists, use something like:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
<br />
To confirm any configuration changes and enact them:<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
'''More Information'''<br />
<br />
Introduction to Antispam Practices - [http://www.howtoforge.com/introduction_antispam_practices| here]<br />
<br />
Here is another great [http://mirror.contribs.org/smeserver//contribs/rmitchell/smeserver/howto/Spam%20blocking%20HOWTO%20using%20qpsmtpd%20&%20RBL%20for%20sme%20server.htm] howto.<br />
<br />
Informative URLs:<br />
* http://forums.contribs.org/index.php?topic=35178.0 <br />
* http://forums.contribs.org/index.php?topic=31278.0<br />
* http://forums.contribs.org/index.php?topic=31279.0<br />
* http://forums.contribs.org/index.php?topic=32158.0<br />
* http://mirror.contribs.org/smeserver/contribs/michaelw/sme7/<br />
* http://mirror.contribs.org/smeserver/contribs/bread/mailstats/<br />
* http://wiki.apache.org/spamassassin/BayesInSpamAssassin<br />
* Enter this command at a console:<br />
perldoc Mail::SpamAssassin::Conf <br />
Last Updated ( Thursday, 21 June 2007 )<br />
<br />
===Email Clients===<br />
===="concurrency limit reached" when using IMAP====<br />
Sometime shows as Thunderbird giving this error message,<br />
''This Mail-server is not a imap4 mail-server''<br />
<br />
To workaround thunderbirds limitations change, this thunderbird setting to false<br />
* Preferences, Advanced, Config editor (aka about:config): filter on tls.<br />
* set security.enable_tls to false<br />
<br />
You can also increase the ConcurrencyLimitPerIP and/or ConcurrencyLimit value for imap and/or imaps (secure)<br />
config setprop imap ConcurrencyLimitPerIP 20<br />
config setprop imaps ConcurrencyLimitPerIP 20<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
check<br />
config show imap<br />
tail -f /var/log/imap/current | tai64nlocal<br />
<br />
More detail can be found [http://forums.contribs.org/index.php?topic=33124.0 here].<br />
<br />
====Mail server is not an IMAP4 mail server====<br />
This is a bug in Thunderbird, the previous tips may help<br />
<br />
====The Bat====<br />
The gives this error message, but they are wrong.<br><br />
"This server uses TLS v3.0 which is considered to be obsolete and insecure. <br />
The server must use TLS v3.1 or above."<br />
<br />
<br />
====Outlook/Outlook Express give error 10060/0x800CCC90====<br />
Most likely OUTLOOK (EXPRESS) isn't configured correctly.<br />
<br />
-open OUTLOOK<br />
-click TOOLS > ACCOUNTS<br />
-click CHANGE (on the right-hand side)<br />
-find INCOMING MAIL SERVER & OUTGOING MAIL SERVER (on right-hand side)<br />
-type: mail.yourdomain.tld (in both places)<br />
-click MORE SETTINGS (on bottom-right)<br />
-click OUTGOING SERVER tab (at the top)<br />
-checkmark "MY OUTGOING SERVER REQUIRES AUTHENTICATION"<br />
-bullet "USE SAME SETTINGS AS INCOMING MAIL SERVER"<br />
-click ADVANCED tab (at the top)<br />
-find OUTGOING SERVER<br />
-checkmark "THIS SERVER REQUIRES A SECURE CONNECTION" (under outgoing server)<br />
-change 25 to 465<br />
-[possibly required, secure IMAP is 993]<br />
-click OK > NEXT > FINISHED<br />
-you're finished, your email should work now<br />
<br />
====Outlook test message doesn't come through====<br />
You clicked the TEST ACCOUNT SETTINGS in OUTLOOK didn't you? This is a bug in OUTLOOK. The test message sends a test email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. To test, send an actual message from OUTLOOK.<br />
<br />
If you want, you can try THUNDERBIRD. It's like OUTLOOK but made by a different company. It's completely free and works very well at home and at the office.<br />
<br />
====I can't receive/send email from my application (ACT!, vTiger, MS Outlook, etc)====<br />
Most likely, this is a bug the application you're using and not a problem with the SMESERVER. The application sends an email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. <br />
<br />
As a workaround you can disable the check for the 'Date header'.<br />
To disable this check on the internal interface:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
To disable this check for the external interface: <br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
====After I upgrade my SME Server, my email folders have disappeared when using IMAP====<br />
After upgrade, if there are missing IMAP folders, the client may need to re-subscribe to folders. This may affect either webmail users or users who use an IMAP email client.<br />
<br />
====Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4====<br />
The main problem here is that Microsoft has decided that Entourage will only support trusted, PEM Base-64 Encoded certificates. To use IMAPS or SMTPS from Entourage with your SME server, you will need to:<br />
1. Login to your Mac as a user with administrative privileges<br />
<br />
2. Open Safari and browse to https://''smeserver''/server-manager. <br />
When you receive the warning about your certificate:<br />
- click on "Show Certificate"<br />
- click and drag the gold-rimmed image of a certificate to your desktop. <br />
You will now have ''myserver.mydomain.tld.cer'' on your desktop.<br />
<br />
3. Locate and open the '''Microsoft Cert Manager'''<br />
- "Import" the certificate you downloaded in step 2.<br />
<br />
4. Highlight the imported certificate and "Export" it. <br />
- Select the "PEM..." format<br />
- add "''pem.''" to the beginning of the filename<br />
- export it to your Desktop<br />
<br />
5. Double-click on the new ''pem.myserver.mydomain.tld.cer'' <br />
- Apple's '''Keychain Access''' application will open.<br />
- Select the '''X509Anchors''' Keychain and click "OK"<br />
<br />
6. While still in Apple's '''Keychain Access''', select the "Certificates" category<br />
- Drag ''pem.myserver.mydomain.tld.cer'' into the certificates window.<br />
<br />
You should now be able to connect to your SME from your Entourage using IMAPS. <br />
<br />
If you are accessing your SME server using a different name than the one encoded in the certificate you will still receive a security warning from Entourage, but "OK" will now grant access to your folders.<br />
<br />
Notes: <br />
* Procedure mostly taken from http://www.kerio.com/manual/kmsug/en/ch09s06.html<br />
* I still get various other IMAP errors due, I suspect, to the "concurrency limit reached" issue.<br />
* Click on "Show Keychains" in Apple's "Keychain Access" if you need to delete a certificate and try again.<br />
<br />
====How do I get my e-mail to show the correct From Address====<br />
<br />
The From address on an e-mail is not supplied by the server. It is supplied by the e-mail client.<br />
<br />
* Configure your Account in your e-mail client with the correct FROM address.<br />
* You can change the FROM address in webmail with the following:<br />
**Login to webmail as the user, go to ''options-personal information'' and change the ''identity'' to have the correct FROM address. You can have multiple identities with a single user.<br />
<br />
===Server Settings===<br />
====Double bounce messages====<br />
To stop admin receiving double bounce messages<br />
<br />
config setprop qmail DoubleBounceTo someoneuser<br />
signal-event email-update<br />
<br />
Or just delete them. You risk losing legitimate double bounces (which are<br />
rare, but you want to look at them when they do occur)<br />
<br />
config setprop qmail DoubleBounceTo devnull<br />
signal-event email-update<br />
<br />
see a longer explaination [[Email_delete_double-bounce_messages | here]]<br />
<br />
====Keep a copy of all emails====<br />
You may need to keep a copy of all emails sent to or from your email server.<br />
This may be for legal, or other reasons.<br />
<br />
The following instructions will create a new user account (maillog) and forward every email that goes through your SME server to it.<br />
<br />
First, log onto the server-manager and create the user '''maillog'''<br />
<br />
Go to the SME Command Line (logon as root) and issue the following commands:<br />
<br />
config setprop qpsmtpd Bcc enabled<br />
signal-event email-update<br />
<br />
Optionally make the forwarding of the emails invisible to the end user. Without it, there will be an X-Copied-To: header in each email. Run this command before the signal-event<br />
<br />
config setprop qpsmtpd BccMode bcc<br />
<br />
If you want to view the emails, point your email client at the SME and log on as maillog.<br />
<br />
====Set max email size====<br />
There are several components involved in sending email on a SME server. Each component has a size limit that may affect an email message that passes through the server.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
! Subsystem<br />
! Function<br />
! Default Limit<br />
! Command to change size<br />
! Notes<br />
|-<br />
|qmail<br />
|Delivers email to local mailboxes and to remote servers<br />
|15000000<br />
|config&nbsp;setprop&nbsp;qmail&nbsp;MaxMessageSize&nbsp;xx000000<br />
|Value is in BYTES. 15000000 equals approximately 15MB<br />
|-<br />
|clamav<br />
|Used to scan emails and attachments<br />
|15M<br />
|config&nbsp;setprop&nbsp;clamav&nbsp;MaxFileSize&nbsp;15M<br />
|value includes human-readable abbreviations. "15M" equlas 15 MegaBytes.<br />
|-<br />
|qpsmtpd<br />
|The clamav plugin to qpsmtpd is called with a specified size limit.<br />
|25000000<br />
|config&nbsp;setprop&nbsp;qpsmtpd&nbsp;MaxScannerSize&nbsp;xx000000<br />
|Value is in BYTES.<br>Question: does this value override the setting of 'MaxFileSize', or will the smaller value prevail?<br />
|-<br />
|php<br />
|The php maximum file upload size will determine the largest file you can attach to an email message using horde (or any other php email client)<br />
|10M<br />
|config&nbsp;setprop&nbsp;php&nbsp;UploadMaxFilesize&nbsp;10M<br />
|<br />
|-<br />
|}<br />
A note about clamav:<br><br />
ClamAV includes settings to prevent the scanning of archives that could cause problems if fully expanded; if an attachment cannot be scanned, it will be rejected.<br />
<br />
These attributes could result in the rejection of a compressed attachment on a SME server:<br />
* ArchiveMaxCompressionRatio (default 300)<br />
* MaxFiles (default 1500)<br />
* MaxRecursion (default 8)<br />
<br />
====Add the admin user as an administrator for Horde====<br />
<br />
config setprop horde Administration enabled <br />
signal-event email-update<br />
<br />
==== Large attachments not displaying in webmail ====<br />
Due to limits set in the PHP configuration it might be that webmail will not display large attachments (see also [[bugzilla:3990]]). The following entries are related to the error and can be found in the log files:<br />
<br />
'''/var/log/messages'''<br />
Mar 13 00:00:12 box1 httpd: PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 154 bytes) in /home/httpd/html/horde/imp/lib/MIME/Contents.php on line 173<br />
<br />
'''/var/log/httpd/error_log'''<br />
Allowed memory size of 33554432 bytes exhausted (tried to allocate 0 bytes)<br />
<br />
The default MemoryLimit setting in PHP is set to 32M the value can be changed using the commands below replacing ''XX'' with the value you desire.<br />
{{Note box|You can set the MemoryLimit any value you like but be sure to add the capital M as a suffix for Megabytes.}}<br />
db configuration setprop php MemoryLimit XXM<br />
expand-template /etc/php.ini<br />
sv t httpd-e-smith<br />
<br />
====Disable mail to a user from an external network====<br />
Can be either a user, pseudonym or group<br />
db accounts setprop groupname/username Visible internal<br />
signal-event email-update<br />
<br />
====I can't receive mail at: user@mail.domain.tld====<br />
Add mail.domain.tld as a virtualdomain.<br />
-login to SERVER-MANAGER<br />
-click DOMAINS (on the left)<br />
-click ADD<br />
-type: mail.domain.tld<br />
<br />
====How do I find out who is logged into webmail and what IP number.====<br />
This is logged is in /var/log/messages.<br />
<br />
====How do I enable smtp authentication for users on the internal network.====<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cp /etc/e-smith/templates/var/service/qpsmtpd/config/peers/0/05auth_cvm_unix_local .<br />
signal-event email-update<br />
(note the "." at the end of the 3rd line)<br><br />
Authentication for the local network will now follow the setting of config::qpsmtpd::Authentication<br />
<br />
====How do I disable SMTP relay for unauthenticated LAN clients====<br />
http://forums.contribs.org/index.php?topic=38797.msg176490#msg176490<br />
* Enable smtp authentication as shown above<br />
* Disable un-authenticated smtp relay for the local network(s)using:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients<br />
echo "# SMTP Relay from local network denied by custom template" >\<br />
/etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients/80relayFromLocalNetwork<br />
signal-event email-update<br />
<br />
* Configure your email clients to use smtps with authentication:<br><br />
- change outgoing smtp port to 465 and select SSL<br><br />
- enable Authentication against the outgoing mail server<br />
<br />
<br />
====Internet provider's port 25 is blocked: How to set an alternative port for the SMTP server====<br />
If your provider is blocking smtp port 25 on your internet connection but your hosting provider is offering an alternative port (or when using some relay service) you can simply set this alternative port by adding it to the 'Address of Internet provider's mail server' value in the 'E-mail delivery settings' screen of the server-manager like this:<br />
<internet providers mail server name or ip-address>:<alternative port><br />
For example: mail.mydomain.com:587<br />
<br />
====How do I enable and configure a disclaimer in email messages====<br />
<br />
<br />
A disclaimer message can be added to the footer of all outgoing email messages.<br />
<br />
The message can be the same for all domains or it can be different for all domains.<br />
<br />
This functionality is part of sme7.2 release so make sure you have upgraded before doing this.<br />
<br />
To create a general disclaimer for all domains on your sme server<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer<br />
Enter the required disclaimer text <br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
To make the changes take effect<br />
signal-event email-update<br />
<br />
<br />
To create domain specific disclaimers, create seperate domain based disclaimer text files<br />
<br />
Delete the general (all domains) disclaimer file if you have already created it<br />
rm /service/qpsmtpd/config/disclaimer<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer_domain1.com.au<br />
pico -w /service/qpsmtpd/config/disclaimer_domain2.com<br />
pico -w /service/qpsmtpd/config/disclaimer_domain3.org<br />
<br />
Enter the required text in each disclaimer file<br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
After making any changes remember to do<br />
signal-event email-update<br />
<br />
<br />
Note if you only wish to have a disclaimer for some domains, then only create a disclaimer text file for those domains <br />
<br />
<br />
Note also the criteria for when a disclaimer is attached <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648)<br />
<br />
eg a disclaimer is added to internal to external messages but not internal to internal messages.<br />
<br />
There are also various switches that can be applied <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648).<br />
<br />
<br />
To disable the disclaimer function for all domains on your sme server<br />
config setprop smtpd disclaimer disabled<br />
signal-event email-update<br />
<br />
<br />
====Email WBL server manager panel====<br />
<br />
There is a server manager contrib to allow GUI control of email white and black lists.<br />
<br />
The panel allows easy configuration of functionality that is built into qmail, qpsmtpd and spamassassin. For more information google for qmail & qpsmtpd, read the spamassassin section in this wiki article and see [http://wiki.contribs.org/Email#Default_Plugin_Configuration default qpsmtpd plugin confguration]).<br />
<br />
{{Warning box|It is a test release, although it has been in use since Jan 2007 and appears functionaly stable. To install do:<br />
wget http://mirror.contribs.org/smeserver/contribs/dmay/smeserver/7.x/testing/smeserver-wbl/smeserver-wbl-0.0.1-a8.dmay.noarch.rpm <br />
rpm -Uvh smeserver-wbl*.rpm<br />
}}<br />
<br />
There are two main sections, Reject and Accept, where you can control settings.<br />
<br />
Reject - Black lists are used for rejecting e-mail traffic<br />
<br />
DNSBL status - DNSBL is an abbreviation for "DNS blacklist". <br />
It is a list of IP addresses known to be spammers.<br />
RHSBL status - RHSBL is an abbreviation for "Right Hand Side Blacklist". <br />
It is a list of domain names known to be spammers.<br />
qpsmtpd badhelo - Check a HELO message delivered from a connecting host. <br />
Reject any that appear in badhelo during the 'helo' stage.<br />
qmail badmailfrom - Check envelope sender addresses. <br />
Reject any that appear (@host or user@host) in badmailfrom during the 'mail' <br />
stage.<br />
<br />
Accept - White lists are used for accepting e-mail traffic<br />
<br />
Whitelists status - White Lists: ACCEPT<br />
qpsmtpd whitelisthosts - Any IP address listed in whitelisthosts will be exempted <br />
from any further validation during the 'connect' stage.<br />
qpsmtpd whitelisthelo - Any host that issues a HELO matching an entry in whitelisthelo <br />
will be exempted from further validation during the 'helo' stage.<br />
qpsmtpd whitelistsenders - Any envelope sender of a mail (@host or user@host) matching an <br />
entry in whitelistsenders will be exempted from further validation<br />
during the 'mail' stage.<br />
spamassassin whitelist_from - Any envelope sender of a mail (*@host or user@host) matching an <br />
entry in whitelist_from will be exempted from spamassassin rejection.<br />
<br />
<br />
After making any changes using this panel you must click both the Save and Update buttons, in order for changes to take effect.<br />
<br />
===External Access===<br />
====Allow external IMAP mail access====<br />
There was a deliberate decision to remove non-SSL protected username/password<br />
services from the external interface.<br />
<br />
to allow unsecure IMAP access<br />
<br />
config setprop imap access public<br />
signal-event email-update<br />
<br />
But before you do this try to use secure IMAP<br><br />
fixme: explain how<br />
<br />
====POP3 & webmail HTTP====<br />
I want to set my SMESERVER to allow POP3 (or webmail HTTP) but it's not an option, I only see POP3S (or webmail HTTPS).<br />
<br />
The SMESERVER is secure by design. POP3 (or webmail HTTP) is viewed as inadequate security and removed as an option from a standard installation to encourage unknowing administrators to select the 'best practice' option -a secure connection with POP3S, IMAPS, or HTTPS.<br />
<br />
You can still set your SMESERVER to allow POP3 settings by:<br />
config setprop pop3 access public<br />
signal-event email-update<br />
<br />
====Allow external pop3 access====<br />
<br />
Email settings > POP3 server access in SME 7.1 server-manager allows only pop3s protocol for clients outside the LAN. Some email clients (eg The Bat! v3.98.4) won't allow pop3s connections to SME 7.1 because of ssl version conflict. Until this is sorted out, a workaround is to hack SME to allow regular pop3 on the external interface using the following commands. <br />
<br />
config setprop pop3 access public<br />
signal-event email-update<br />
svc -t /service/pop3s <br />
<br />
more information [[bugzilla:2620]]<br />
<br />
===Imap===<br />
====Folders with a dot in name====<br />
Email folder names that have a period ('.') in the folder name, will be split into sub-folders.<br />
e.g. folder name 'www.contribs.org' is created as<br />
www<br />
contribs<br />
org<br />
<br />
===qpsmtpd===<br />
SME uses the [http://smtpd.develooper.com qpsmtpd] smtp daemon.<br />
<br />
====Official Description====<br />
qpsmtpd is a flexible smtpd daemon written in Perl. Apart from the core SMTP features, all functionality is implemented in small "extension plugins" using the easy to use object oriented plugin API.<br />
<br />
qpsmtpd was originally written as a drop-in qmail-smtpd replacement, but now it also includes smtp forward, postfix, exim and maildir "backends".<br />
<br />
qpsmtpd wiki: http://wiki.qpsmtpd.org <br />
<br />
<br />
====Default Plugin Configuration====<br />
SME uses the following [http://wiki.qpsmtpd.org/plugins qpsmtpd plugins] to evaluate each incoming email. <br />
<br />
SME maintains 2 distinct configurations: one for the 'local' networks (as defined in server-manager::Security::Local networks) and another for 'remote' networks (everyone else).<br />
<br />
The default configuration of each plugin is indicated in the 'Default Status' column.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
!Plugin<br />
!Purpose<br />
!Default Status<br />
|-<br />
|hosts_allow<br />
|Prohibit more than "InstancesPerIP" connections from any single host (change with 'config setprop smtp InstancesPerIP'). Allow or deny connections according to the contents of /var/service/qpsmtpd/config/hosts_allow. See [http://svn.perl.org/qpsmtpd/trunk/plugins/hosts_allow hosts_allow SVN code] for more details.<br />
|[http://bugs.contribs.org/show_bug.cgi?id=3352 upcoming]<br />
|-<br />
|peers<br />
|Allow different plugin configuration based on the sending computer's IP address. By default SME maintains different configurations for the local networks (in /var/service/qpsmtpd/config/peers/local) and for everyone else (in /var/service/qpsmtpd/config/peers/0)<br />
|enabled<br />
|-<br />
|logging/logterse<br />
|Allow greater logging detail using smaller log files<br />
|enabled<br />
|-<br />
|auth/auth_cvm_unix_local<br />
|Allow authenticated smtp relay<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_earlytalker<br />
|reject email from servers that talk out of turn<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|count_unrecognized_commands<br />
|reject email from servers that issue ''X'' invalid commands<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|bcc<br />
|bcc all email to a specific address for archiving<br />
|'''disabled'''<br />
|-<br />
|check_relay<br />
|Check to see if relaying is allowed (in case the recipient is not listed in one of SME's local domains)<br />
|enabled<br />
|-<br />
|check_norelay<br />
|Check to see if the sending server is specifically forbidden to relay through us.<br />
|enabled<br />
|-<br />
|require_resolvable_fromhost<br />
|Check that the domain listed in the sender's email address is resolvable<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_basicheaders<br />
|reject email that lacks either a From: or Date: header<br />
|enabled<br />
|-<br />
|rhsbl<br />
|Reject email if the sender's email domain has a reputation for disregarding smtp RFCs.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|dnsbl<br />
|Reject email from hosts listed in your configured dnsbl servers<br />
|'''disabled'''<br />
|-<br />
|check_badmailfrom<br />
|Reject email where the sender address is listed in /var/service/qpsmtpd/config/badmailfrom<br />
|enabled<br />
|-<br />
|check_badrcptto_patterns<br />
|Reject email addressed to any address matching an expression listed in /var/service/qpsmtpd/config/badrcptto_patterns<br />
|enabled<br />
|-<br />
|check_badrcptto<br />
|Reject email addressed to any address listed in /var/service/qpsmtpd/config/badrcptto<br />
|enabled<br />
|-<br />
|check_spamhelo<br />
|Reject email from hosts that say 'helo ...' using a value in /var/service/qpsmtpd/config/badhelo<br />
|enabled<br />
|-<br />
|check_smtp_forward<br />
|If ''config show DelegateMailServer'' or ''db domains show <domainname> MailServer'' is set (telling SME to deliver email for all domains or just <domainname> to another server), check_smtp_forward will connect to the specified server and will reject the message outright if the internal mail server would also reject it.<br />
|'''disabled'''<br>unless an internal mail server is configured.<br />
|-<br />
|check_goodrcptto<br />
|Accept email only if the recipient address matches an entry in /var/service/qpsmtpd/config/goodrcptto. For domains that are configured to use an internal mail server, the entire domain name will be added to .../goodrcptto.<br />
|enabled<br />
|-<br />
|rcpt_ok<br />
|Return 'OK' if none of the other host checks has returned 'DENY' (??)<br />
|enabled<br />
|-<br />
|pattern_filter<br />
|Reject email according to content patterns (??)<br />
|'''disabled'''<br />
|-<br />
|tnef2mime<br />
|Convert MS TNEF (winmail.dat) and uuencoded attachments to MIME<br />
|enabled<br />
|-<br />
|disclaimer<br />
|Add a configurable disclaimer to email messages<br />
|'''disabled'''<br />
|-<br />
|spamassassin<br />
|Check email using spamassassin, and optionally reject it completely if the score exceeds a configurable value.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|virus/clamav <br />
|Scan incoming email with ClamAV<br />
|enabled<br />
|-<br />
|queue/qmail-queue<br />
|Deliver the incoming message to qmail for delivery.<br />
|enabled<br />
|-<br />
|}<br />
<br />
===Internal Mail Servers===<br />
SME can be configured as a spam and antivirus filter for one or more "Internal" mail servers on a domain-by-domain basis. The mail server specified does not have to be on the same local network as your SME server.<br />
<br />
====Deliver ALL email to a single internal mail server====<br />
You can deliver all email for all domains on your SME server to a single internal mail server by setting the mail server address in server-manager::Configuration::E-mail::Change e-mail delivery settings::Address of internal mail server.<br />
<br />
====Deliver email for one domain to an internal mail server====<br />
You can also configure only a single domain to use an internal mail server, or you can configure different domains to use different internal mail servers.<br />
<br />
First, create the necessary virtual domains using server-manager::Configuration::Domains::Add Domain.<br />
<br />
Then, (assuming your domain is called ''test.com'' and the actual mail server is at ''a.b.c.d'' issue the following commands:<br />
db domains setprop test.com MailServer a.b.c.d<br />
signal-event email-update<br />
<br />
=== Secondary/Backup Mail Server Considerations ===<br />
<br />
Many people misunderstand the issues of using a secondary or backup <br />
mail server (backup MX) to hold your mail before it gets delivered <br />
to your SME Server. If you consider putting a backup mail server in <br />
place because you are concerned about lost mail because your internet<br />
connection may occasionally drop out, think again and consider the issues<br />
discussed below.<br />
<br />
====What is ''Backup MX''====<br />
<br />
A backup MX is a system whereby through your DNS records you tell other<br />
servers on the internet that in order to deliver mail to your domain they<br />
first need to try the primary MX record and if they fail to connect they<br />
can try to connect to one or more of your listed backup or secondary mail <br />
servers. See also http://en.wikipedia.org/wiki/MX_record<br />
<br />
====The process of delivering email to your SME Server====<br />
<br />
So lets look at how mail gets delivered without and with a <br />
''backup mx'' when your Internet link, ISP or server is down.<br />
<br />
====='''Without''' a backup MX=====<br />
<br />
* The sending mail server cannot connect to your server.<br />
* The sending mail server MUST queue the mail and try again later.<br />
* The mail stays on the sender's server.<br />
* The sender's server resends the mail at a later date.<br />
<br />
''The requirement to re-queue is a fundamental part of the SMTP protocol - <br />
it is not optional. So, if your server is '''offline''' due to a link or ISP <br />
outage, '''the mail just stays at the sender's server until you are once <br />
again reachable'''.<br />
<br />
====='''With''' a backup MX=====<br />
<br />
* The sending mail server cannot contact your server.<br />
* The sending mail server sends the mail to your secondary MX.<br />
* The secondary MX queues the mail until your link/server is up.<br />
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'').<br />
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs.<br />
* You have no, or little, visibility over the queued mail.<br />
* When your link comes up, the secondary MX sends the mail on to your server.<br />
* You have added more hops, more systems and more delay to the process.<br />
<br />
If you think that a backup MX will protect against broken mail servers <br />
which don't re-queue, you can't. Those servers will drop mail on the floor<br />
at random times, for example when ''their'' Internet link is down. <br />
<br />
Those servers are also highly likely to never try your backup MX. <br />
<br />
Thankfully those servers are mostly gone from the Internet, but adding a <br />
secondary MX doesn't really improve the chances that they won't drop mail<br />
destined for your server on the floor.<br />
<br />
====Backup MX and SPAM Filtering====<br />
<br />
On top of the issue, indicated above, there is another issue to consider<br />
and that is what happens with SPAM due to the use of a ''Backup MX''. <br />
<br />
Your SME Server takes care of filtering a lot of SPAM by checking on the full <br />
username & domain at the time it is received.<br />
<br />
For example if your server hosts '''example.com''' and someone sends <br />
mail to '''joeuser@example.com''', the server will '''only''' accept the mail<br />
if joeuser is a local user/alias/group/pseudonym on the server. <br />
Otherwise, the mail is rejected during the SMTP transaction.<br />
<br />
A backup mail server however, generally does not have a full list of<br />
users against which it can check if it should accept the mail for the given<br />
domain. Hence it will accept mail for ''invalid'' users.<br />
<br />
So:<br />
<br />
* If you trust the secondary MX, you <u>will</u> accept a lot of SPAM when the link comes up.<br />
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.<br />
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.<br />
<br />
The SPAM backscatter can only be stopped if the secondary MX has a full list<br />
of users for your domain to allow filtering to occur.<br />
<br />
But:<br />
<br />
* You need to be able to configure this secondary MX with such user/domain lists<br />
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration<br />
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.<br />
<br />
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find <br />
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail. <br />
<br />
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.<br />
<br />
* If you bounce mail at your server, you have logs to show what's wrong. <br />
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.<br />
<br />
==== Summary ====<br />
<br />
In summary, if your server/Internet connection is available most (let's say >90%) of <br />
the time, you are generally better off <u>without a secondary MX</u>. <br />
<br />
If your server/link is down more than this (e.g. dialup), you should not be delivering mail <br />
directly to your server.<br />
<br />
If you still want to consider setting up a seconday MX, ensure that:<br />
<br />
* you have fully control of the configuration of each of the email gateways for your domain<br />
* each gateway can make decisions on whether to accept/reject mail for the users at the domain<br />
<br />
<br />
<noinclude>[[Category:Howto]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=Email&diff=10145
Email
2008-06-23T20:55:00Z
<p>Mercyh: /* Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4 */</p>
<hr />
<div>==Email==<br />
===Spam===<br />
====Spamassassin====<br />
Set spamassassin for automatically delete junkmail.<br />
You can change the "days" that spamassassin sets to automatically delete junkmail, to delete after two months <br />
<br />
db configuration setprop spamassassin MessageRetentionTime 60 <br />
signal-event email-update <br />
<br />
<br />
The "Custom spam rejection level" will only work when "Spam sensitivity" is set to custom.<br />
<ol></li><li>Open server-manager.<br />
</li><li>Click e-mail in the navigation pane (left-hand side).<br />
</li><li>Click Change e-mail filtering settings.<br />
</li><li>Change "Spam sensitivity" to custom and adjust the settings to your liking.<br />
</li></ol><br />
<br />
This happens because by default, no mail (except for viruses) gets rejected without the admin doing something first.<br />
<br />
====='''X-Spam-Level Header in Email Messages'''=====<br />
SME does not create an X-Spam-Level header in processed email messages by default.<br />
<br />
To enable this capability:<br />
/usr/bin/yum install --enablerepo=smecontribs smeserver-qpsmtpd-spamassassinlevelstars<br />
signal-event email-update<br />
<br />
(Based on [[Bugzilla:3505]])<br />
<br />
=====Custom Rule Scores=====<br />
You can customize the score assigned by a specific Spamassassin rule (SARE_ADULT2 in this case) as follows:<br />
mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf<br />
echo "score SARE_ADULT2 20.000" >> 20localscores<br />
signal-event email-update<br />
<br />
You can now add additional tests and custom scores by editing the newly-created template fragment ''20localscores'' and adding new custom scores using:<br />
pico -w /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
Each custom score goes on its own line. If you enter a score surrounded by parentheses, the "custom" score will be added to the default score for the specified test (use ''score TEST_NAME (-1)'' to reduce the score for 'TEST_NAME' by 1) <br />
<br />
You can remove these customizations using: <br />
rm -f /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/20localscores<br />
signal-event email-update<br />
<br />
References:<br />
* http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#scoring_options<br />
* http://spamassassin.apache.org/tests_3_2_x.html<br />
* http://www.rulesemporium.com/<br />
<br />
====Real-time Blackhole List (RBL)====<br />
Enabling RBL's <br><br />
RBL's are disabled by default to allow maximum accommodation (your ISP may be on a RBL & you may not know it). You can enable RBL's by:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
signal-event email-update<br />
<br />
You can see your RBL's by:<br />
config show qpsmtpd<br />
<br />
You can add to your RBL's by:<br />
config setprop qpsmtpd RBLList <rbl-list-name><br />
signal-event email-update<br />
<br />
Many will argue what's best but most would agree that you can set best-practice recommended settings by:<br />
config setprop qpsmtpd RBLList zen.spamhaus.org:whois.rfc-ignorant.org:dnsbl.njabl.org<br />
signal-event email-update<br />
<br />
Note: More information on this topic can be found here:<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#RHSBL_Servers]<br />
[http://wiki.contribs.org/Updating_to_SME_7.2#DNSBL_Servers]<br />
<br />
====Server Only====<br />
Some of the spam filter rules cannot work unless the SMESERVER knows the external IP of the box. If you put a SMESERVER in server-only mode behind other firewalls, it will lose some of the anti-spam rules. For example, the rule that blocks attempts where spammers try "HELO a.b.c.d" where a.b.c.d is your external IP address.<br />
<br />
Unfortunately, many admins believe that port-forwarding SMTP provides additional security. It doesn't, it limits the SMESERVER's ability to apply some rules.<br />
<br />
<br />
====I want to enable GreyListing====<br />
GreyListing support is under the covers and can easily be enabled for those who know what they are doing. However, many experienced users found that they spent more time looking after the greylisting configuration than they received in benefit.<br />
<br />
====Setup Blacklists & Bayesian Autolearning====<br />
<br />
(Much of what follows has been shamelessly copied from the Sonoracomm howto)<br />
<br />
The default SME settings (as you can see [http://wiki.contribs.org/Email#Default_Plugin_Configuration here]) do not include DNSBL filtering, spam rejection, or (which is not obvious from the above) bayesian filtering in spamassassin to allow spamassassin to learn from received email and improve over time.<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set<br />
thresholds for the bayesian filter.<br />
<br />
config setprop spamassassin UseBayes 1<br />
config setprop spamassassin BayesAutoLearnThresholdSpam 4.00<br />
config setprop spamassassin BayesAutoLearnThresholdNonspam 0.10<br />
expand-template /etc/mail/spamassassin/local.cf<br />
sa-learn --sync --dbpath /var/spool/spamd/.spamassassin -u spamd<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes_*<br />
chown spamd.spamd /var/spool/spamd/.spamassassin/bayes.mutex<br />
chmod 640 /var/spool/spamd/.spamassassin/bayes_* <br />
config setprop qpsmtpd DNSBL enabled<br />
config setprop qpsmtpd RHSBL enabled<br />
config setprop spamassassin status enabled<br />
config setprop spamassassin RejectLevel 12<br />
config setprop spamassassin TagLevel 4<br />
config setprop spamassassin Sensitivity custom<br />
signal-event email-update<br />
<br />
These commands will:<br />
* enable spamassassin<br />
* configure spamassassin to reject any email with a score above 12<br />
* tag spam scored between 4 and 12 in the email header<br />
* enable bayesian filter<br />
* 'autolearn' as SPAM any email with a score above 4.00<br />
* 'autolearn' as HAM any email with a score below 0.10<br />
* enable RHSBL using the default SBLList. Note that rhsbl checking has been known to place a heavy burden on SME servers.<br />
* enable DNSBL using the default RBLList<br />
<br />
====The entire Sonoracomm howto from Google's text cache====<br />
* The Sonoracomm HowTo has been a very well regarded set of instructions for SME mail server configuration for quite a while.<br />
<br />
* This section was created during an extended outage of the Sonoracomm web server (in 2007?)<br />
<br />
* The Sonoracomm HowTo has been updated since this section was created, and is well worth examining. View the current version at: http://www.sonoracomm.com/index.php?option=com_content&task=view&id=49&Itemid=32<br />
<br />
* The content below has been modified to include changes suggested in the bug tracker and forums.<br />
<br />
* These instructions are aimed mostly at configuring SME as the only mail server, not for using SME with an internal mail server. (Specifically, LearnAsSpam.pl is harder to configure when using an internal mail server - you would have to develop a method for getting the unmarked SPAM into an IMAP folder directly on the SME server itself. Not impossible, but difficult!)<br />
<br />
'''SONORA COMMUNICATIONS, INC.'''<br />
<br />
This is a quick configuration howto, not an in-depth look at SpamAssassin. Much more can be done<br />
beyond this document, but this will take a big dent out of your spam and free up CPU cycles on your server.<br />
<br />
See 'More Information' at the end.<br />
<br />
'''SpamAssassin'''<br />
<br />
The following command will enable the default blacklists, enable the bayesian learning filter and set thresholds for the bayesian filter.<br />
<nowiki>rpm -Uvh \<br />
http://mirror.contribs.org/smeserver/contribs/\<br />
michaelw/sme7/smeserver-spamassassin-features-0.0.2-0.noarch.rpm</nowiki><br />
<br />
This command will install the FuzzyOCR SA plugin designed to catch those nasty image-based spam messages.<br />
yum -y --enablerepo=smeupdates-testing install FuzzyOcr<br />
<br />
'''Server-Manager'''<br />
<br />
Using the Server-Manager Configuration/E-Mail panel, adjust the settings to these reasonable <br />
* Virus scanning Enabled<br />
* Spam filtering Enabled<br />
* Spam sensitivity Custom<br />
* Custom spam tagging level 4<br />
* Custom spam rejection level 12<br />
* Sort spam into junkmail folder Enabled<br />
* Modify subject of spam messages Enabled<br />
<br />
It is also recommend blocking all executable content. To do so, select (highlight) all of the attachment types other than zip files (the last two).<br />
<br />
Click Save.<br />
<br />
'''How It Works'''<br />
<br />
When receiving an incoming message, the server first tests for RBL and DNSBL listings, if enabled. If the sender is blacklisted, the messages are blocked outright and Spamassassin never sees it. <br />
<br />
With this configuration, the spammiest messages, those marked as 12 or above, will be rejected at the SMTP level. Those spam messages marked between 4 and 12, will be routed to the users' (IMAP) junkmail folder. This is done so the users can check for false-positives...valid messages that were classified as spam by SpamAssassin.<br />
<br />
Users may check their junkmail folders for false-positives via webmail, or, if they are using an IMAP mail client, by simply checking the junkmail folder exposed by their mail client.<br />
<br />
https://servername/webmail<br />
<br />
'''Tweaking'''<br />
<br />
The server will automatically delete old spam in the junkmail folders after 90 days. You can control the number of days old spam is kept with the following commands. Where 15 is the number of days you want to keep messages, do...<br />
<br />
db configuration setprop spamassassin MessageRetentionTime 15<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
then<br />
<br />
config show spamassassin<br />
<br />
If you think you are losing misclassified mail, adjust the ''Custom spam rejection level'' higher.<br />
<br />
If too much spam is making through to your inbox, carefully adjust the 'Custom spam tagging level' down. Many people use the level 4. Anything below that may result in false-positives. YMMV.<br />
<br />
If too much spam is building up in your (IMAP) junkmail folder, adjust the 'Custom spam rejection level' down or change the number of days spam is kept in the junkmail folder before being automatically deleted by the server.<br />
<br />
'''Bayesian (Learning) Filter'''<br />
<br />
Install the LearnAsSpam.pl, (optional) mailstats and sa-update scripts, then configure nightly cron jobs like this:<br />
<nowiki>cd /usr/bin<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.pl<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/spamfilter-stats-7.pl<br />
cd /etc/cron.d<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/LearnAsSpam.cron<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/mailstats.cron<br />
cd /etc/cron.daily<br />
wget http://mirror.contribs.org/smeserver/\<br />
contribs//bread/mailstats/sa-update<br />
chmod +x sa-update<br />
/etc/rc.d/init.d/crond restart</nowiki><br />
<br />
Using an IMAP mail client, create a new folder called 'LearnAsSpam' (case sensitive). It can be created at the top level (like 'Inbox') or as a sub-folder. Create the folder for each user that will help train the Bayesian filter. Webmail will work fine for creating this folder, as well as for checking the junkmail (filtered mail or quarantine) folder.<br />
<br />
If any spam messages make it past the filter and into your inbox, just move them into the LearnAsSpam folder. A nightly cron job will process them and delete them for you. This is how you train the Bayesian filter.<br />
<br />
'''Testing'''<br />
<br />
You can check the auto-learning statistics with this command. You will be able to note the accumulation of the spam tokens (or not). Note that the Bayesian filtering must receive 200 spam messages before it starts to function, so don't expect instantaneous results.<br />
sa-learn --dump magic<br />
<br />
You can check the spam filter log with this command: <br />
tail -50 /var/log/spamd/current | tai64nlocal<br />
<br />
If you ever see an error such as:<br />
''warn: bayes: cannot open bayes databases /etc/mail/spamassassin/bayes_* R/W: tie failed: Permission denied''<br />
Try adjusting some permissions with these commands:<br />
chown :spamd /var/spool/spamd/.spamassassin/*<br />
chmod g+rw /var/spool/spamd/.spamassassin/* <br />
<br />
'''Whitelist and Blacklist'''<br />
<br />
If mail comes in and it is misclassified as spam (and moved to the junkmail folder when that feature is enabled), you can add the sender to the whitelist so that future messages coming in from that sender are not filtered.<br />
<br />
Conversely, you can add a spammer to the blacklist so you never see their spam again. <br />
<br />
Add senders (or their entire domains) to the global whitelist (or blacklist) with commands similar to these (as root):<br />
db spamassassin setprop wbl.global *@vonage.com White<br />
db spamassassin setprop wbl.global *domain2.com White<br />
db spamassassin setprop wbl.global badname@baddomain.com Black<br />
db spamassassin setprop wbl.global *@verybaddomain.com Black<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it White<br />
db spamassassin setprop wbl.global This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can enter multiple addresses/domains for both white and black lists in one command<br />
db spamassassin setprop wbl.global name@domain.com White *domain2.com White *domain3.com Black<br />
expand-template /etc/mail/spamassassin/local.cf<br />
svc -t /service/spamd<br />
<br />
You can view the lists with this command:<br />
db spamassassin show<br />
<br />
You can delete one or more entries from the white/blacklist using<br />
db spamassassin delprop wbl.global name@domain.com *domain2.com<br />
* name@domain.com and *domain2.com must exactly match a value in the output from ''db spamassassin show'' to the ''left'' of the equals sign. <br />
* You do not need to specify ''White'' or ''Black'' when deleting entries.<br />
<br />
<br />
<br />
'''Clam Antivirus'''<br />
<br />
Update and check your Clam Antivirus with this command. This is normally done automatically every hour via cron.<br />
freshclam -v<br />
<br />
or<br />
freshclam --debug<br />
<br />
Verify hourly update checking by viewing the freshclam/current log file via the Server-Manager View Log Files panel.<br />
<br />
'''Realtime Blackhole Lists and DNS Blacklists'''<br />
<br />
To view the settings for the RBL and DNSBL, use this command:<br />
config show qpsmtpd<br />
<br />
If you followed the instructions above, both checks are enabled.<br />
<br />
To see the log of these tests, use a command like:<br />
tail /var/log/qpsmtpd/current | tai64nlocal <br />
<br />
To specify multiple RBLs, use a command like this:<br />
config setprop qpsmtpd RBLList \<br />
bl.spamcop.net,combined.njabl.org,dnsbl.ahbl.org,dnsbl-1.uceprotect.net,\<br />
list.dsbl.org,multihop.dsbl.org,psbl.surriel.com,zen.spamhaus.org<br />
<br />
Note: we have had trouble with the uceprotect.net level 2 list and sometimes remove it from the list as shown here.<br />
<br />
To enable or disable both available lists, use something like:<br />
config setprop qpsmtpd DNSBL enabled RHSBL enabled<br />
<br />
To confirm any configuration changes and enact them:<br />
signal-event email-update<br />
svc -t /service/qpsmtpd<br />
<br />
'''More Information'''<br />
<br />
Introduction to Antispam Practices - [http://www.howtoforge.com/introduction_antispam_practices| here]<br />
<br />
Here is another great [http://mirror.contribs.org/smeserver//contribs/rmitchell/smeserver/howto/Spam%20blocking%20HOWTO%20using%20qpsmtpd%20&%20RBL%20for%20sme%20server.htm] howto.<br />
<br />
Informative URLs:<br />
* http://forums.contribs.org/index.php?topic=35178.0 <br />
* http://forums.contribs.org/index.php?topic=31278.0<br />
* http://forums.contribs.org/index.php?topic=31279.0<br />
* http://forums.contribs.org/index.php?topic=32158.0<br />
* http://mirror.contribs.org/smeserver/contribs/michaelw/sme7/<br />
* http://mirror.contribs.org/smeserver/contribs/bread/mailstats/<br />
* http://wiki.apache.org/spamassassin/BayesInSpamAssassin<br />
* Enter this command at a console:<br />
perldoc Mail::SpamAssassin::Conf <br />
Last Updated ( Thursday, 21 June 2007 )<br />
<br />
===Email Clients===<br />
===="concurrency limit reached" when using IMAP====<br />
Sometime shows as Thunderbird giving this error message,<br />
''This Mail-server is not a imap4 mail-server''<br />
<br />
To workaround thunderbirds limitations change, this thunderbird setting to false<br />
* Preferences, Advanced, Config editor (aka about:config): filter on tls.<br />
* set security.enable_tls to false<br />
<br />
You can also increase the ConcurrencyLimitPerIP and/or ConcurrencyLimit value for imap and/or imaps (secure)<br />
config setprop imap ConcurrencyLimitPerIP 20<br />
config setprop imaps ConcurrencyLimitPerIP 20<br />
signal-event post-upgrade; signal-event reboot<br />
<br />
check<br />
config show imap<br />
tail -f /var/log/imap/current | tai64nlocal<br />
<br />
More detail can be found [http://forums.contribs.org/index.php?topic=33124.0 here].<br />
<br />
====Mail server is not an IMAP4 mail server====<br />
This is a bug in Thunderbird, the previous tips may help<br />
<br />
====The Bat====<br />
The gives this error message, but they are wrong.<br><br />
"This server uses TLS v3.0 which is considered to be obsolete and insecure. <br />
The server must use TLS v3.1 or above."<br />
<br />
<br />
====Outlook/Outlook Express give error 10060/0x800CCC90====<br />
Most likely OUTLOOK (EXPRESS) isn't configured correctly.<br />
<br />
-open OUTLOOK<br />
-click TOOLS > ACCOUNTS<br />
-click CHANGE (on the right-hand side)<br />
-find INCOMING MAIL SERVER & OUTGOING MAIL SERVER (on right-hand side)<br />
-type: mail.yourdomain.tld (in both places)<br />
-click MORE SETTINGS (on bottom-right)<br />
-click OUTGOING SERVER tab (at the top)<br />
-checkmark "MY OUTGOING SERVER REQUIRES AUTHENTICATION"<br />
-bullet "USE SAME SETTINGS AS INCOMING MAIL SERVER"<br />
-click ADVANCED tab (at the top)<br />
-find OUTGOING SERVER<br />
-checkmark "THIS SERVER REQUIRES A SECURE CONNECTION" (under outgoing server)<br />
-change 25 to 465<br />
-[possibly required, secure IMAP is 993]<br />
-click OK > NEXT > FINISHED<br />
-you're finished, your email should work now<br />
<br />
====Outlook test message doesn't come through====<br />
You clicked the TEST ACCOUNT SETTINGS in OUTLOOK didn't you? This is a bug in OUTLOOK. The test message sends a test email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. To test, send an actual message from OUTLOOK.<br />
<br />
If you want, you can try THUNDERBIRD. It's like OUTLOOK but made by a different company. It's completely free and works very well at home and at the office.<br />
<br />
====I can't receive/send email from my application (ACT!, vTiger, MS Outlook, etc)====<br />
Most likely, this is a bug the application you're using and not a problem with the SMESERVER. The application sends an email with 'no Date header'. As the name suggests, this means a message without any date. Since the server doesn't accept mail with 'no Date header' (because it's required) the message is rejected. <br />
<br />
As a workaround you can disable the check for the 'Date header'.<br />
To disable this check on the internal interface:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
To disable this check for the external interface: <br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0<br />
echo "# 17check_basicheaders disabled by custom template" > \<br />
17check_basicheaders<br />
signal-event email-update<br />
<br />
====After I upgrade my SME Server, my email folders have disappeared when using IMAP====<br />
After upgrade, if there are missing IMAP folders, the client may need to re-subscribe to folders. This may affect either webmail users or users who use an IMAP email client.<br />
<br />
====Entourage: Using SME's Self-Signed Certificate for SSL Connections from Entourage on OS X 10.4====<br />
The main problem here is that Microsoft has decided that Entourage will only support trusted, PEM Base-64 Encoded certificates. To use IMAPS or SMTPS from Entourage with your SME server, you will need to:<br />
1. Login to your Mac as a user with administrative privileges<br />
<br />
2. Open Safari and browse to https://''smeserver''/server-manager. <br />
When you receive the warning about your certificate:<br />
- click on "Show Certificate"<br />
- click and drag the gold-rimmed image of a certificate to your desktop. <br />
You will now have ''myserver.mydomain.tld.cer'' on your desktop.<br />
<br />
3. Locate and open the '''Microsoft Cert Manager'''<br />
- "Import" the certificate you downloaded in step 2.<br />
<br />
4. Highlight the imported certificate and "Export" it. <br />
- Select the "PEM..." format<br />
- add "''pem.''" to the beginning of the filename<br />
- export it to your Desktop<br />
<br />
5. Double-click on the new ''pem.myserver.mydomain.tld.cer'' <br />
- Apple's '''Keychain Access''' application will open.<br />
- Select the '''X509Anchors''' Keychain and click "OK"<br />
<br />
6. While still in Apple's '''Keychain Access''', select the "Certificates" category<br />
- Drag ''pem.myserver.mydomain.tld.cer'' into the certificates window.<br />
<br />
You should now be able to connect to your SME from your Entourage using IMAPS. <br />
<br />
If you are accessing your SME server using a different name than the one encoded in the certificate you will still receive a security warning from Entourage, but "OK" will now grant access to your folders.<br />
<br />
Notes: <br />
* Procedure mostly taken from http://www.kerio.com/manual/kmsug/en/ch09s06.html<br />
* I still get various other IMAP errors due, I suspect, to the "concurrency limit reached" issue.<br />
* Click on "Show Keychains" in Apple's "Keychain Access" if you need to delete a certificate and try again.<br />
<br />
===How do I get my e-mail to show the correct From Address===<br />
<br />
The From address on an e-mail is not supplied by the server. It is supplied by the e-mail client.<br />
<br />
* Configure your Account in your e-mail client with the correct FROM address.<br />
* You can change the FROM address in webmail with the following:<br />
**Login to webmail as the user, go to ''options-personal information'' and change the ''identity'' to have the correct FROM address. You can have multiple identities with a single user.<br />
<br />
===Server Settings===<br />
====Double bounce messages====<br />
To stop admin receiving double bounce messages<br />
<br />
config setprop qmail DoubleBounceTo someoneuser<br />
signal-event email-update<br />
<br />
Or just delete them. You risk losing legitimate double bounces (which are<br />
rare, but you want to look at them when they do occur)<br />
<br />
config setprop qmail DoubleBounceTo devnull<br />
signal-event email-update<br />
<br />
see a longer explaination [[Email_delete_double-bounce_messages | here]]<br />
<br />
====Keep a copy of all emails====<br />
You may need to keep a copy of all emails sent to or from your email server.<br />
This may be for legal, or other reasons.<br />
<br />
The following instructions will create a new user account (maillog) and forward every email that goes through your SME server to it.<br />
<br />
First, log onto the server-manager and create the user '''maillog'''<br />
<br />
Go to the SME Command Line (logon as root) and issue the following commands:<br />
<br />
config setprop qpsmtpd Bcc enabled<br />
signal-event email-update<br />
<br />
Optionally make the forwarding of the emails invisible to the end user. Without it, there will be an X-Copied-To: header in each email. Run this command before the signal-event<br />
<br />
config setprop qpsmtpd BccMode bcc<br />
<br />
If you want to view the emails, point your email client at the SME and log on as maillog.<br />
<br />
====Set max email size====<br />
There are several components involved in sending email on a SME server. Each component has a size limit that may affect an email message that passes through the server.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
! Subsystem<br />
! Function<br />
! Default Limit<br />
! Command to change size<br />
! Notes<br />
|-<br />
|qmail<br />
|Delivers email to local mailboxes and to remote servers<br />
|15000000<br />
|config&nbsp;setprop&nbsp;qmail&nbsp;MaxMessageSize&nbsp;xx000000<br />
|Value is in BYTES. 15000000 equals approximately 15MB<br />
|-<br />
|clamav<br />
|Used to scan emails and attachments<br />
|15M<br />
|config&nbsp;setprop&nbsp;clamav&nbsp;MaxFileSize&nbsp;15M<br />
|value includes human-readable abbreviations. "15M" equlas 15 MegaBytes.<br />
|-<br />
|qpsmtpd<br />
|The clamav plugin to qpsmtpd is called with a specified size limit.<br />
|25000000<br />
|config&nbsp;setprop&nbsp;qpsmtpd&nbsp;MaxScannerSize&nbsp;xx000000<br />
|Value is in BYTES.<br>Question: does this value override the setting of 'MaxFileSize', or will the smaller value prevail?<br />
|-<br />
|php<br />
|The php maximum file upload size will determine the largest file you can attach to an email message using horde (or any other php email client)<br />
|10M<br />
|config&nbsp;setprop&nbsp;php&nbsp;UploadMaxFilesize&nbsp;10M<br />
|<br />
|-<br />
|}<br />
A note about clamav:<br><br />
ClamAV includes settings to prevent the scanning of archives that could cause problems if fully expanded; if an attachment cannot be scanned, it will be rejected.<br />
<br />
These attributes could result in the rejection of a compressed attachment on a SME server:<br />
* ArchiveMaxCompressionRatio (default 300)<br />
* MaxFiles (default 1500)<br />
* MaxRecursion (default 8)<br />
<br />
====Add the admin user as an administrator for Horde====<br />
<br />
config setprop horde Administration enabled <br />
signal-event email-update<br />
<br />
==== Large attachments not displaying in webmail ====<br />
Due to limits set in the PHP configuration it might be that webmail will not display large attachments (see also [[bugzilla:3990]]). The following entries are related to the error and can be found in the log files:<br />
<br />
'''/var/log/messages'''<br />
Mar 13 00:00:12 box1 httpd: PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 154 bytes) in /home/httpd/html/horde/imp/lib/MIME/Contents.php on line 173<br />
<br />
'''/var/log/httpd/error_log'''<br />
Allowed memory size of 33554432 bytes exhausted (tried to allocate 0 bytes)<br />
<br />
The default MemoryLimit setting in PHP is set to 32M the value can be changed using the commands below replacing ''XX'' with the value you desire.<br />
{{Note box|You can set the MemoryLimit any value you like but be sure to add the capital M as a suffix for Megabytes.}}<br />
db configuration setprop php MemoryLimit XXM<br />
expand-template /etc/php.ini<br />
sv t httpd-e-smith<br />
<br />
====Disable mail to a user from an external network====<br />
Can be either a user, pseudonym or group<br />
db accounts setprop groupname/username Visible internal<br />
signal-event email-update<br />
<br />
====I can't receive mail at: user@mail.domain.tld====<br />
Add mail.domain.tld as a virtualdomain.<br />
-login to SERVER-MANAGER<br />
-click DOMAINS (on the left)<br />
-click ADD<br />
-type: mail.domain.tld<br />
<br />
====How do I find out who is logged into webmail and what IP number.====<br />
This is logged is in /var/log/messages.<br />
<br />
====How do I enable smtp authentication for users on the internal network.====<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cd /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local<br />
cp /etc/e-smith/templates/var/service/qpsmtpd/config/peers/0/05auth_cvm_unix_local .<br />
signal-event email-update<br />
(note the "." at the end of the 3rd line)<br><br />
Authentication for the local network will now follow the setting of config::qpsmtpd::Authentication<br />
<br />
====How do I disable SMTP relay for unauthenticated LAN clients====<br />
http://forums.contribs.org/index.php?topic=38797.msg176490#msg176490<br />
* Enable smtp authentication as shown above<br />
* Disable un-authenticated smtp relay for the local network(s)using:<br />
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients<br />
echo "# SMTP Relay from local network denied by custom template" >\<br />
/etc/e-smith/templates-custom/var/service/qpsmtpd/config/relayclients/80relayFromLocalNetwork<br />
signal-event email-update<br />
<br />
* Configure your email clients to use smtps with authentication:<br><br />
- change outgoing smtp port to 465 and select SSL<br><br />
- enable Authentication against the outgoing mail server<br />
<br />
<br />
====Internet provider's port 25 is blocked: How to set an alternative port for the SMTP server====<br />
If your provider is blocking smtp port 25 on your internet connection but your hosting provider is offering an alternative port (or when using some relay service) you can simply set this alternative port by adding it to the 'Address of Internet provider's mail server' value in the 'E-mail delivery settings' screen of the server-manager like this:<br />
<internet providers mail server name or ip-address>:<alternative port><br />
For example: mail.mydomain.com:587<br />
<br />
====How do I enable and configure a disclaimer in email messages====<br />
<br />
<br />
A disclaimer message can be added to the footer of all outgoing email messages.<br />
<br />
The message can be the same for all domains or it can be different for all domains.<br />
<br />
This functionality is part of sme7.2 release so make sure you have upgraded before doing this.<br />
<br />
To create a general disclaimer for all domains on your sme server<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer<br />
Enter the required disclaimer text <br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
To make the changes take effect<br />
signal-event email-update<br />
<br />
<br />
To create domain specific disclaimers, create seperate domain based disclaimer text files<br />
<br />
Delete the general (all domains) disclaimer file if you have already created it<br />
rm /service/qpsmtpd/config/disclaimer<br />
config setprop smtpd disclaimer enabled<br />
pico -w /service/qpsmtpd/config/disclaimer_domain1.com.au<br />
pico -w /service/qpsmtpd/config/disclaimer_domain2.com<br />
pico -w /service/qpsmtpd/config/disclaimer_domain3.org<br />
<br />
Enter the required text in each disclaimer file<br />
<br />
To save & exit<br />
Ctrl o<br />
Ctrl x<br />
After making any changes remember to do<br />
signal-event email-update<br />
<br />
<br />
Note if you only wish to have a disclaimer for some domains, then only create a disclaimer text file for those domains <br />
<br />
<br />
Note also the criteria for when a disclaimer is attached <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648)<br />
<br />
eg a disclaimer is added to internal to external messages but not internal to internal messages.<br />
<br />
There are also various switches that can be applied <br />
<br />
(see http://bugs.contribs.org/show_bug.cgi?id=2648).<br />
<br />
<br />
To disable the disclaimer function for all domains on your sme server<br />
config setprop smtpd disclaimer disabled<br />
signal-event email-update<br />
<br />
<br />
====Email WBL server manager panel====<br />
<br />
There is a server manager contrib to allow GUI control of email white and black lists.<br />
<br />
The panel allows easy configuration of functionality that is built into qmail, qpsmtpd and spamassassin. For more information google for qmail & qpsmtpd, read the spamassassin section in this wiki article and see [http://wiki.contribs.org/Email#Default_Plugin_Configuration default qpsmtpd plugin confguration]).<br />
<br />
{{Warning box|It is a test release, although it has been in use since Jan 2007 and appears functionaly stable. To install do:<br />
wget http://mirror.contribs.org/smeserver/contribs/dmay/smeserver/7.x/testing/smeserver-wbl/smeserver-wbl-0.0.1-a8.dmay.noarch.rpm <br />
rpm -Uvh smeserver-wbl*.rpm<br />
}}<br />
<br />
There are two main sections, Reject and Accept, where you can control settings.<br />
<br />
Reject - Black lists are used for rejecting e-mail traffic<br />
<br />
DNSBL status - DNSBL is an abbreviation for "DNS blacklist". <br />
It is a list of IP addresses known to be spammers.<br />
RHSBL status - RHSBL is an abbreviation for "Right Hand Side Blacklist". <br />
It is a list of domain names known to be spammers.<br />
qpsmtpd badhelo - Check a HELO message delivered from a connecting host. <br />
Reject any that appear in badhelo during the 'helo' stage.<br />
qmail badmailfrom - Check envelope sender addresses. <br />
Reject any that appear (@host or user@host) in badmailfrom during the 'mail' <br />
stage.<br />
<br />
Accept - White lists are used for accepting e-mail traffic<br />
<br />
Whitelists status - White Lists: ACCEPT<br />
qpsmtpd whitelisthosts - Any IP address listed in whitelisthosts will be exempted <br />
from any further validation during the 'connect' stage.<br />
qpsmtpd whitelisthelo - Any host that issues a HELO matching an entry in whitelisthelo <br />
will be exempted from further validation during the 'helo' stage.<br />
qpsmtpd whitelistsenders - Any envelope sender of a mail (@host or user@host) matching an <br />
entry in whitelistsenders will be exempted from further validation<br />
during the 'mail' stage.<br />
spamassassin whitelist_from - Any envelope sender of a mail (*@host or user@host) matching an <br />
entry in whitelist_from will be exempted from spamassassin rejection.<br />
<br />
<br />
After making any changes using this panel you must click both the Save and Update buttons, in order for changes to take effect.<br />
<br />
===External Access===<br />
====Allow external IMAP mail access====<br />
There was a deliberate decision to remove non-SSL protected username/password<br />
services from the external interface.<br />
<br />
to allow unsecure IMAP access<br />
<br />
config setprop imap access public<br />
signal-event email-update<br />
<br />
But before you do this try to use secure IMAP<br><br />
fixme: explain how<br />
<br />
====POP3 & webmail HTTP====<br />
I want to set my SMESERVER to allow POP3 (or webmail HTTP) but it's not an option, I only see POP3S (or webmail HTTPS).<br />
<br />
The SMESERVER is secure by design. POP3 (or webmail HTTP) is viewed as inadequate security and removed as an option from a standard installation to encourage unknowing administrators to select the 'best practice' option -a secure connection with POP3S, IMAPS, or HTTPS.<br />
<br />
You can still set your SMESERVER to allow POP3 settings by:<br />
config setprop pop3 access public<br />
signal-event email-update<br />
<br />
====Allow external pop3 access====<br />
<br />
Email settings > POP3 server access in SME 7.1 server-manager allows only pop3s protocol for clients outside the LAN. Some email clients (eg The Bat! v3.98.4) won't allow pop3s connections to SME 7.1 because of ssl version conflict. Until this is sorted out, a workaround is to hack SME to allow regular pop3 on the external interface using the following commands. <br />
<br />
config setprop pop3 access public<br />
signal-event email-update<br />
svc -t /service/pop3s <br />
<br />
more information [[bugzilla:2620]]<br />
<br />
===Imap===<br />
====Folders with a dot in name====<br />
Email folder names that have a period ('.') in the folder name, will be split into sub-folders.<br />
e.g. folder name 'www.contribs.org' is created as<br />
www<br />
contribs<br />
org<br />
<br />
===qpsmtpd===<br />
SME uses the [http://smtpd.develooper.com qpsmtpd] smtp daemon.<br />
<br />
====Official Description====<br />
qpsmtpd is a flexible smtpd daemon written in Perl. Apart from the core SMTP features, all functionality is implemented in small "extension plugins" using the easy to use object oriented plugin API.<br />
<br />
qpsmtpd was originally written as a drop-in qmail-smtpd replacement, but now it also includes smtp forward, postfix, exim and maildir "backends".<br />
<br />
qpsmtpd wiki: http://wiki.qpsmtpd.org <br />
<br />
<br />
====Default Plugin Configuration====<br />
SME uses the following [http://wiki.qpsmtpd.org/plugins qpsmtpd plugins] to evaluate each incoming email. <br />
<br />
SME maintains 2 distinct configurations: one for the 'local' networks (as defined in server-manager::Security::Local networks) and another for 'remote' networks (everyone else).<br />
<br />
The default configuration of each plugin is indicated in the 'Default Status' column.<br />
{| width="100%" border="1" cellpadding="5" cellspacing="0"<br />
!Plugin<br />
!Purpose<br />
!Default Status<br />
|-<br />
|hosts_allow<br />
|Prohibit more than "InstancesPerIP" connections from any single host (change with 'config setprop smtp InstancesPerIP'). Allow or deny connections according to the contents of /var/service/qpsmtpd/config/hosts_allow. See [http://svn.perl.org/qpsmtpd/trunk/plugins/hosts_allow hosts_allow SVN code] for more details.<br />
|[http://bugs.contribs.org/show_bug.cgi?id=3352 upcoming]<br />
|-<br />
|peers<br />
|Allow different plugin configuration based on the sending computer's IP address. By default SME maintains different configurations for the local networks (in /var/service/qpsmtpd/config/peers/local) and for everyone else (in /var/service/qpsmtpd/config/peers/0)<br />
|enabled<br />
|-<br />
|logging/logterse<br />
|Allow greater logging detail using smaller log files<br />
|enabled<br />
|-<br />
|auth/auth_cvm_unix_local<br />
|Allow authenticated smtp relay<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_earlytalker<br />
|reject email from servers that talk out of turn<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|count_unrecognized_commands<br />
|reject email from servers that issue ''X'' invalid commands<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|bcc<br />
|bcc all email to a specific address for archiving<br />
|'''disabled'''<br />
|-<br />
|check_relay<br />
|Check to see if relaying is allowed (in case the recipient is not listed in one of SME's local domains)<br />
|enabled<br />
|-<br />
|check_norelay<br />
|Check to see if the sending server is specifically forbidden to relay through us.<br />
|enabled<br />
|-<br />
|require_resolvable_fromhost<br />
|Check that the domain listed in the sender's email address is resolvable<br />
|enabled (remote)<br>'''disabled (local)'''<br />
|-<br />
|check_basicheaders<br />
|reject email that lacks either a From: or Date: header<br />
|enabled<br />
|-<br />
|rhsbl<br />
|Reject email if the sender's email domain has a reputation for disregarding smtp RFCs.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|dnsbl<br />
|Reject email from hosts listed in your configured dnsbl servers<br />
|'''disabled'''<br />
|-<br />
|check_badmailfrom<br />
|Reject email where the sender address is listed in /var/service/qpsmtpd/config/badmailfrom<br />
|enabled<br />
|-<br />
|check_badrcptto_patterns<br />
|Reject email addressed to any address matching an expression listed in /var/service/qpsmtpd/config/badrcptto_patterns<br />
|enabled<br />
|-<br />
|check_badrcptto<br />
|Reject email addressed to any address listed in /var/service/qpsmtpd/config/badrcptto<br />
|enabled<br />
|-<br />
|check_spamhelo<br />
|Reject email from hosts that say 'helo ...' using a value in /var/service/qpsmtpd/config/badhelo<br />
|enabled<br />
|-<br />
|check_smtp_forward<br />
|If ''config show DelegateMailServer'' or ''db domains show <domainname> MailServer'' is set (telling SME to deliver email for all domains or just <domainname> to another server), check_smtp_forward will connect to the specified server and will reject the message outright if the internal mail server would also reject it.<br />
|'''disabled'''<br>unless an internal mail server is configured.<br />
|-<br />
|check_goodrcptto<br />
|Accept email only if the recipient address matches an entry in /var/service/qpsmtpd/config/goodrcptto. For domains that are configured to use an internal mail server, the entire domain name will be added to .../goodrcptto.<br />
|enabled<br />
|-<br />
|rcpt_ok<br />
|Return 'OK' if none of the other host checks has returned 'DENY' (??)<br />
|enabled<br />
|-<br />
|pattern_filter<br />
|Reject email according to content patterns (??)<br />
|'''disabled'''<br />
|-<br />
|tnef2mime<br />
|Convert MS TNEF (winmail.dat) and uuencoded attachments to MIME<br />
|enabled<br />
|-<br />
|disclaimer<br />
|Add a configurable disclaimer to email messages<br />
|'''disabled'''<br />
|-<br />
|spamassassin<br />
|Check email using spamassassin, and optionally reject it completely if the score exceeds a configurable value.<br />
|'''disabled'''<br>(always disabled for local connections)<br />
|-<br />
|virus/clamav <br />
|Scan incoming email with ClamAV<br />
|enabled<br />
|-<br />
|queue/qmail-queue<br />
|Deliver the incoming message to qmail for delivery.<br />
|enabled<br />
|-<br />
|}<br />
<br />
===Internal Mail Servers===<br />
SME can be configured as a spam and antivirus filter for one or more "Internal" mail servers on a domain-by-domain basis. The mail server specified does not have to be on the same local network as your SME server.<br />
<br />
====Deliver ALL email to a single internal mail server====<br />
You can deliver all email for all domains on your SME server to a single internal mail server by setting the mail server address in server-manager::Configuration::E-mail::Change e-mail delivery settings::Address of internal mail server.<br />
<br />
====Deliver email for one domain to an internal mail server====<br />
You can also configure only a single domain to use an internal mail server, or you can configure different domains to use different internal mail servers.<br />
<br />
First, create the necessary virtual domains using server-manager::Configuration::Domains::Add Domain.<br />
<br />
Then, (assuming your domain is called ''test.com'' and the actual mail server is at ''a.b.c.d'' issue the following commands:<br />
db domains setprop test.com MailServer a.b.c.d<br />
signal-event email-update<br />
<br />
=== Secondary/Backup Mail Server Considerations ===<br />
<br />
Many people misunderstand the issues of using a secondary or backup <br />
mail server (backup MX) to hold your mail before it gets delivered <br />
to your SME Server. If you consider putting a backup mail server in <br />
place because you are concerned about lost mail because your internet<br />
connection may occasionally drop out, think again and consider the issues<br />
discussed below.<br />
<br />
====What is ''Backup MX''====<br />
<br />
A backup MX is a system whereby through your DNS records you tell other<br />
servers on the internet that in order to deliver mail to your domain they<br />
first need to try the primary MX record and if they fail to connect they<br />
can try to connect to one or more of your listed backup or secondary mail <br />
servers. See also http://en.wikipedia.org/wiki/MX_record<br />
<br />
====The process of delivering email to your SME Server====<br />
<br />
So lets look at how mail gets delivered without and with a <br />
''backup mx'' when your Internet link, ISP or server is down.<br />
<br />
====='''Without''' a backup MX=====<br />
<br />
* The sending mail server cannot connect to your server.<br />
* The sending mail server MUST queue the mail and try again later.<br />
* The mail stays on the sender's server.<br />
* The sender's server resends the mail at a later date.<br />
<br />
''The requirement to re-queue is a fundamental part of the SMTP protocol - <br />
it is not optional. So, if your server is '''offline''' due to a link or ISP <br />
outage, '''the mail just stays at the sender's server until you are once <br />
again reachable'''.<br />
<br />
====='''With''' a backup MX=====<br />
<br />
* The sending mail server cannot contact your server.<br />
* The sending mail server sends the mail to your secondary MX.<br />
* The secondary MX queues the mail until your link/server is up.<br />
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'').<br />
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs.<br />
* You have no, or little, visibility over the queued mail.<br />
* When your link comes up, the secondary MX sends the mail on to your server.<br />
* You have added more hops, more systems and more delay to the process.<br />
<br />
If you think that a backup MX will protect against broken mail servers <br />
which don't re-queue, you can't. Those servers will drop mail on the floor<br />
at random times, for example when ''their'' Internet link is down. <br />
<br />
Those servers are also highly likely to never try your backup MX. <br />
<br />
Thankfully those servers are mostly gone from the Internet, but adding a <br />
secondary MX doesn't really improve the chances that they won't drop mail<br />
destined for your server on the floor.<br />
<br />
====Backup MX and SPAM Filtering====<br />
<br />
On top of the issue, indicated above, there is another issue to consider<br />
and that is what happens with SPAM due to the use of a ''Backup MX''. <br />
<br />
Your SME Server takes care of filtering a lot of SPAM by checking on the full <br />
username & domain at the time it is received.<br />
<br />
For example if your server hosts '''example.com''' and someone sends <br />
mail to '''joeuser@example.com''', the server will '''only''' accept the mail<br />
if joeuser is a local user/alias/group/pseudonym on the server. <br />
Otherwise, the mail is rejected during the SMTP transaction.<br />
<br />
A backup mail server however, generally does not have a full list of<br />
users against which it can check if it should accept the mail for the given<br />
domain. Hence it will accept mail for ''invalid'' users.<br />
<br />
So:<br />
<br />
* If you trust the secondary MX, you <u>will</u> accept a lot of SPAM when the link comes up.<br />
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.<br />
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.<br />
<br />
The SPAM backscatter can only be stopped if the secondary MX has a full list<br />
of users for your domain to allow filtering to occur.<br />
<br />
But:<br />
<br />
* You need to be able to configure this secondary MX with such user/domain lists<br />
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration<br />
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.<br />
<br />
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find <br />
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail. <br />
<br />
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.<br />
<br />
* If you bounce mail at your server, you have logs to show what's wrong. <br />
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.<br />
<br />
==== Summary ====<br />
<br />
In summary, if your server/Internet connection is available most (let's say >90%) of <br />
the time, you are generally better off <u>without a secondary MX</u>. <br />
<br />
If your server/link is down more than this (e.g. dialup), you should not be delivering mail <br />
directly to your server.<br />
<br />
If you still want to consider setting up a seconday MX, ensure that:<br />
<br />
* you have fully control of the configuration of each of the email gateways for your domain<br />
* each gateway can make decisions on whether to accept/reject mail for the users at the domain<br />
<br />
<br />
<noinclude>[[Category:Howto]]</noinclude></div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10144
Netkeeper Remote Server Monitor
2008-06-23T17:56:00Z
<p>Mercyh: /* Netkeeper Remote Server Monitor */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10143
Netkeeper Remote Server Monitor
2008-06-23T17:55:45Z
<p>Mercyh: /* Usage */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
{{Incomplete}}<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
<br />
===Usage===<br />
<br />
* The server's status is updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=SME_Server_talk:Netkeeper_Remote_Server_Monitor&diff=10142
SME Server talk:Netkeeper Remote Server Monitor
2008-06-23T17:04:48Z
<p>Mercyh: New page: Page started by Royce Holdeman. Please feel free to edit or discuss any needed changes here. rh at mercyh dot org</p>
<hr />
<div>Page started by Royce Holdeman. Please feel free to edit or discuss any needed changes here.<br />
<br />
rh at mercyh dot org</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10141
Netkeeper Remote Server Monitor
2008-06-23T16:58:54Z
<p>Mercyh: /* Configuring Affa Backup Monitoring */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
{{Incomplete}}<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
<br />
===Usage===<br />
<br />
* The server's status us updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10140
Netkeeper Remote Server Monitor
2008-06-23T16:58:39Z
<p>Mercyh: /* Forum Thread Link */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
{{Incomplete}}<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
<br />
===Usage===<br />
<br />
* The server's status us updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh
https://wiki.koozali.org/index.php?title=Netkeeper_Remote_Server_Monitor&diff=10139
Netkeeper Remote Server Monitor
2008-06-23T16:57:00Z
<p>Mercyh: /* Configuring Affa Backup Monitoring */</p>
<hr />
<div>{{Needs review}}<br />
<br />
===Netkeeper Remote Server Monitor===<br />
<br />
A small Windows based program for continuously monitoring multiple Local or Remote SME servers Over SSH.<br />
{{Incomplete}}<br />
<br />
===Maintainer===<br />
<br />
Gert<br />
<br />
===Forum Thread Link===<br />
<br />
http://forums.contribs.org/index.php?topic=41161.0<br />
<br />
===Installation===<br />
Download the installation files from here:<br />
http://ghp.homelinux.net/contribs/NRSM/<br />
<br />
You will need the ''NSRM_Setup_v'''X'''.'''X'''.zip'' for the base install. You will need ''post.pl'' if you wish to monitor Affa backup jobs on the server.<br />
<br />
# Unzip the ''NSRM_Setup_v'''X.X'''.zip'' file on the windows workstation.<br />
# Run ''setup.exe''.<br />
# Open the Netkeeper Remote Server Monitor program and go to ''Server Maintenance''.<br />
# Click ''Add Server'' and put in your server information. <br />
#*'''Domain''' can be either an IP address or a domain name that resolves to the correct IP.<br />
#*'''SSH port''' can be changed to a non-standard port.<br />
#*'''Password''' is the server's root password.<br />
<br />
*The first time a server's Raid Status is updated it will review the Raid Status, Click "YES" to accept.<br />
<br />
===Usage===<br />
<br />
* The server's status us updated every 5 minutes, but an update can be forced by clicking on "REFRESH"<br />
<br />
*To access a server's console, double-click on the server's domain name.<br />
<br />
*To review a server's Raid status, double-click on the server's RAID status.<br />
<br />
===Configuring Affa Backup Monitoring===<br />
<br />
#Copy or download the post backup script ''post.pl'' to the servers running Affa.<br />
<br />
#Make it executable with "chmod +x post.pl" at the server console.<br />
<br />
#Edit the Affa job configuration file and enter the path to ''post.pl'' for 'postJobCommand'. (The command to edit the job would be something like the following)<br />
#*'db affa setprop ''Affa_Job_Name'' postJobCommand ''Full_Path_to_post.pl''<br />
<br />
See Affa how-to here for reference: http://wiki.contribs.org/Affa#Configuration<br />
<br />
<br />
<br />
[[Category: Contrib]]<br />
[[Category: Webapps]]<br />
[[Category: Administration]]</div>
Mercyh