I had a case:
- Have a service in home local network.
- I would like to access this service from outside.
- I don't have routed IP in home.
- I have VPS with public IP, but I can't run OpenVPN on it.
As workaround you can use SSH tunnel with remote port forwarding.
In my example service is running on machine 192.168.3.28:8080 and I want to have access on port 8090.
First of all you have to add to your /etc/ssh/sshd_config file:
GatewayPorts yes
On my router (it doesn't matter, but it has address 192.168.3.3) I've run command:
ssh -R 8090:192.168.3.28:8080 me@jaqb.gda.pl
This command create a tunnel between server (jaqb.gda.pl) on port 8090 through my router (192.168.3.3) to port 8080 on host 192.168.3.28 in home network.
Now I can access it from anywhere.
In fact, my (great!) VPS provider allow me to run OpenVPN in less than 10 minutes so it wasn't necessary.
You can use Let's encrypt certificates to secure communication with your e-mail server.
After you generate certificate for your mail server:
certbot-auto certonly --apache --non-interactive --agree-tos \ --email me@mydomian -d mail.jaqb.gda.pl
they have to be copied to new location because Postfix/CyrusIMAP cannot read them, the /etc/letsencrypt/live directory can be read only by root.
The solution is simple. I've copied them into /etc/postfix directory and change group to mail:
cp /etc/letsencrypt/live/mail.jaqb.gda.pl/cert.pem \
/etc/postfix/cert.pem
cp /etc/letsencrypt/live/mail.jaqb.gda.pl/privkey.pem \
/etc/postfix/privkey.pem
cp /etc/letsencrypt/live/mail.jaqb.gda.pl/fullchain.pem \
/etc/postfix/fullchain.pem
chgrp mail /etc/postfix/cert.pem /etc/postfix/privkey.pem \
/etc/postfix/fullchain.pem
I've added this commands to /etc/cron.monthly/letsencrypt-auto.bash file (from my last post).
Of course you have to set that appropriate options, at least in /etc/postfix/main.cf:
smtpd_tls_cert_file = /etc/postfix/cert.pem smtpd_tls_key_file = /etc/postfix/privkey.pem smtpd_tls_CAfile = /etc/postfix/fullchain.pem
and in /etc/imapd.conf:
tls_cert_file: /etc/postfix/cert.pem tls_key_file: /etc/postfix/privkey.pem tls_ca_file: /etc/postfix/fullchain.pem
After restart:
/etc/init.d/postfix restart /etc/init.d/cyrus-imapd restart
everything should work. Good luck!
If you want to create a certificate you should download certbot-auto and install them in your system:
wget "https://dl.eff.org/certbot-auto" mv certbot-auto /usr/local/sbin/ chmod u+x /usr/local/sbin/certbot-auto
Then you can request your first (test) certificate:
certbot-auto certonly --test-cert --apache \ --non-interactive --agree-tos --email me@mydomain.com \ -d www.jaqb.gda.pl
If you want to recreate certificate after tests you have to delete them, and then create again (without --test-cert option)
certbot-auto delete -d www.jaqb.gda.pl certbot-auto certonly --apache --non-interactive --agree-tos \ --email me@mydomain.com -d www.jaqb.gda.pl
Of course you can obtain more than one certificate:
certbot-auto certonly --apache --non-interactive --agree-tos \ --email me@mydomain.com -d dev.jaqb.gda.pl
All certificates are stored in /etc/letsencrypt/live directory.
The certificates are valid only for 3 months, but don't worry everything can be automated - I've added to cron (/etc/cron.monthly/letsencrypt-auto.bash):
#!/bin/bash certbot-auto renew --apache --non-interactive --agree-tos \ --email me@mydomain.com
I hope it will work... ;-)
To get images placed on map based on GPS tags in Piwigo (2.9) I had to install and enable "Exiftool GPS" plugin and install exiftools.
I've downloaded it and unpack in /tmp directory:
cd /tmp wget "http://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-10.51.tar.gz" tar -xzf Image-ExifTool-10.51.tar.gz cd Image-ExifTool-10.51
Prepare directory and copy files
mkdir /usr/local/Image-ExifTool-10.51 cp exiftool /usr/local/Image-ExifTool-10.51/exiftool cp -r lib /usr/local/Image-ExifTool-10.51
Prepare symbolic links
cd /usr/local ln -s Image-ExifTool-10.51 Image-ExifTool cd bin ln -s ../Image-ExifTool/exiftool . mkdir /usr/local/lib/site_perl cd /usr/local/lib/site_perl ln -s ../../Image-ExifTool/lib/File ../../Image-ExifTool/lib/Image .
and now it works:
root@NAS:~# exiftool --help Syntax: exiftool [OPTIONS] FILE Consult the exiftool documentation for a full list of options.
Today I've run Domoticz on my NAS (ReadyNAS OS 6 running on Ultra 4). Installation is very simple (in contrast to run on CentOS 7). I've downloaded domoticz from their site:
cd /tmp wget "https://releases.domoticz.com/releases/release/domoticz_linux_x86_64.tgz"
Extracted files:
cd /opt mkdir domoticz-2017-03-13 cd domoticz-2017-03-13 tar -zxf /tmp/domoticz_linux_x86_64.tgz
Created file /lib/systemd/system/domoticz.service:
[Unit] Description=Domoticz uruchoamiany automatycznie After=network.target [Service] ExecStart=/opt/domoticz-2017-03-13/domoticz -daemon KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target
and register service to start automatically :
systemctl enable domoticz systemctl start domoticz
and that's all. Now you can check if it's work: http://192.168.1.1:8080/ - of course you have to change IP address.
First installation. It's simple
yum install postgrey
Turn on automatic start:
chkconfig postgrey on
Check:
chkconfig --list postgrey postgrey 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Add
, check_policy_service unix:/var/spool/postfix/postgrey/socket
in main.cf file as last element smtpd_recipient_restrictions option:
Now it looks like this:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_recipient_domain, check_policy_service unix:/var/spool/postfix/postgrey/socket
Restart postfix. Done.
You can check in maillog if it works:
grep postgrey /var/log/maillog
If you want be able to download all attachments at once you have to explicitly enable zipdownload plugin in config.inc.php file:
$config['plugins'] = array( ... , 'zipdownload' ... );
so simple...
If you would like to use F*EX, but you have only one IP and you can't/don't want to use different port there is a solution!
The Morten Minde Neergaard method almost work. In my case I've prepared file (let's say fex.conf) in /etc/httpd/conf.d/:
<VirtualHost 2.3.4.5:80>
ServerName fex.mydomain.org
ProxyPass / http://127.0.0.1:88/
ProxyPreserveHost On
</VirtualHost>
and setup F*EX (/etc/xinetd.d/fex):
service fex
{
[...]
bind = 127.0.0.1
port = 81
[...]
}
note I've changed also the port F*EX listen on.
The only thing I had to change in F*EX source code was one line added in lib/fex.pp file:
--- fex.pp-2014-11-01 2013-07-27 01:41:43.000000000 +0200
+++ fex.pp 2014-11-01 00:22:19.384463319 +0100
@@ -137,6 +137,8 @@
}
}
+ $port=80;
+
# use same protocal as uploader for download
if ($ENV{PROTO} eq 'https' and $port == 443 or $port == 80) {
$durl = "$ENV{PROTO}://$host/fop";
to fix links to files sent by F*EX to point to port 80 instead of 88. Without this little change links looks like this:
http://fex.mydomain.org:81/fop/NUQLEo5c/testfile.txt
I don't know if there is other method not to sent F*EX port to clients or maybe there are some changes in newest version. I've tested it on, quite old, 20130805 release.
If you want to use Submin, or any other web application that resides outside default Apache directory (/var/www/html) you have to set proper SELinux context for all files. In this case all files are located in /var/lib/submin directory. Without this you will get some error messages in /var/log/audit/audit.log:
avc: denied { write } for pid=1813 comm="python2" name="submin.db" dev=dm-0 ino=664032 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
and in /var/log/messages:
setroubleshoot: SELinux is preventing /usr/bin/python from read access on the file /var/lib/submin/conf/settings.py setroubleshoot: SELinux is preventing /usr/bin/python from read access on the file /var/lib/submin/conf/settings.pyc setroubleshoot: SELinux is preventing /usr/bin/python from write access on the directory /var/lib/submin/conf setroubleshoot: SELinux is preventing /usr/bin/python from getattr access on the file /var/lib/submin/conf/submin.db
You should change context of /var/lib/submin/cgi-bin/submin.cgi to httpd_sys_script_exec_t and whole /var/lib/submin/conf/ directory to httpd_sys_script_rw_t:
cd /var/lib/submin chcon -t httpd_sys_script_exec_t cgi-bin/submin.cgi chcon -R -t httpd_sys_script_rw_t conf
additionally if You want Submin to work with Apache on different port (ie. 88), you have to change http_vhost options:
submin2-admin /var/lib/submin config set http_vhost "http://your.host.com:88"
note there is no tailing slash (/) in address.
Add comment