I have a strange problem that recently popped on my Debian Squeeze server.
I've had Exim4 configured to use SMTP-AUTH with encryption setup and running on this box for a long time, but now it doesn't work.
At first I thought it was maybe my certificates expired, but that wasn't the case, they're good for several more years.
It appears that the server isn't listening on port 25 any longer.
If I try to telnet to port 25 it times out.
If I run netstat -tulpen on the server nothing is listening on port 25.
I'm using the splitconf for Exim4.
In conf.d/main I'm enabling MAIN_TLS_ENABLE=true
In conf.d/auth/30_exim4-config_examples I have the following
# Authenticate against local passwords using sasl2-bin
# Requires exim_uid to be a member of sasl group, see README.Debian.gz
plain_saslauthd_server:
driver = plaintext
public_name = PLAIN
server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}}
server_set_id = $auth2
server_prompts = :
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
#
login_saslauthd_server:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
# don't send system passwords over unencrypted connections
server_condition = ${if saslauthd{{$auth1}{$auth2}}{1}{0}}
server_set_id = $auth1
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
On the server if I run this command:
swaks -a -tls -q HELO -s localhost -au A_USER_NAME -ap '<>'
I get this ...
=== Trying localhost:25...
* Error connecting 0.0.0.0 to localhost:25:
* IO::Socket::INET: connect: Connection refused
Can someone point me to some more advanced debugging techniques?
OK. I figured it out.
Comcast blocks port 25. I don't know why this is coming up now, unless they've recently started blocking it.
I had to change a line in /etc/default/exim4
From this
SMTPLISTENEROPTIONS='-oX 25 -oP /var/run/exim4/exim.pid'
To this
SMTPLISTENEROPTIONS='-oX 465:25 -oP /var/run/exim4/exim.pid'
I also added this to /etc/exim4/conf.d/main/03_exim4-config_tlsoptions
tls_on_connect_ports=465
It's odd that this just popped up, unless a Debian package updated the /etc/default/exim4 file. It's confusing, but it's working. Hopefully this will be helpful to someone in the future.
Cheers.
Related
Until sometime last night, my UBUNTU 20.04 system was working fine with this configuration file at /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.6/24
gateway4: 192.168.1.254
nameservers:
addresses: [192.168.1.2]
This has been working great for a couple of years, but sometime during the evening, connection to 192.168.1.6 was lost from other servers (I know because I had ssh connections that were dropped during the night).
Upon investigation I found that the (normally headless) server had a new IP address (.92 rather than .6), and apparently this configuration file is no longer applicable.
I found that network-manager is in the /etc/init.d/ directory which seems to mean that, for whatever reason, the system is now ignoring that previous configuration. It's a mystery to me why this would suddenly change.
Anyway, I found how to configure NetworkManager for the result I want, and came up with this, which I placed into (new file) /etc/NetworkManager/conf.d/ethernet.conf:
[802-3-ethernet]
auto-negotiate=true
mac-address=b4:2e:99:a2:58:77
[connection]
id=Wired connection 1
uuid=06563f32-7cd9-3ee1-ac71-e5bb775a4840
type=802-3-ethernet
timestamp=0
[ipv6]
method=ignore
[ipv4]
method=manual
dns=192.168.1.2
address1=192.168.1.6/24,192.168.1.254
(I got the uuid value from 'nmcli conn show' and I got the mac addr from 'ip a show eth0')
dennis#velmicro:/etc/NetworkManager 01/10 10:01:12
> nmcli conn show
NAME UUID TYPE DEVICE
Wired connection 1 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ethernet eth0
ls2021.lovelady.com a4fa8d23-a06d-4955-bfd9-5d7de76584c2 wifi wlan0
dennis#velmicro:/etc/NetworkManager 01/10 10:01:30
> ip a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b4:2e:99:a2:58:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.92/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 84428sec preferred_lft 84428sec
Here's what /etc/NetworkManager/NetworkManager.conf looks like:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet
Restarting NetworkManager, and even a complete reboot seems to produce no errors and yet the configuration is apparently ignored: the 192.168.1.92 address persists.
What am I missing to make this system static IP to the address I need?
Bonus points: How would I determine what caused the sudden (apparent) switch to NetworkManager from netplan?
The following commands, entered at the command line as user root, solved this problem:
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.address 192.168.1.6/24
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.gateway 192.168.1.254
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.dns "192.168.1.2"
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.method manual
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.dns-search "lovelady.com"
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv6.method disabled
nmcli connection up 06563f32-7cd9-3ee1-ac71-e5bb775a4840
After executing those commands, the following configuration could be found in /etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection (it was created for me)
[connection]
id=Wired connection 1
uuid=06563f32-7cd9-3ee1-ac71-e5bb775a4840
type=ethernet
autoconnect-priority=-999
interface-name=eth0
permissions=
timestamp=1673626973
[ethernet]
mac-address-blacklist=
[ipv4]
address1=192.168.1.6/24,192.168.1.254
dns=192.168.1.2;
dns-search=lovelady.com;
method=manual
[ipv6]
method=disabled
[proxy]
The placement of a device configuration into the /etc/NetworkManager/conf.d structure was a mistake. No device configurations should be placed into that directory.
Command journalctl -u NetworkManager.service (executable by any user) ultimately helped reveal what was going on, and why the configuration file I created did not have the desired effect.
All device configurations should go under /etc/NetworkManager/system-connections/ and ideally should be created via a sequence of nmcli commands as above.
This device is now (again) configured as I like. Note that the former configuration file (/etc/netplan/01-network-manager-all.yaml) is no longer used by the system, for an unknown reason. ls -lu /etc/netplan/01* reveals that it has not been read in several days, despite a series of reboots.
Am on an Amazon AWS EC2 Linux AMI Server. I used "Bill's Linux Qmail Toaster v. 0.9.4" at Bill's Linux Qmail Toaster v. 0.9.4 to install the various software packages there, specifically: daemontools, ucspi-tcp, qmail, vpopmail, dovecot, squirrel mail, autorespond, ezmlm-idx and qmailadmin. Qmail, Vpopmail and Dovecot are all working well, having tested as below...
Testing SMTP using telnet localhost 25 has no errors.
Testing IMAP using telnet localhost 143 has no errors.
Testing POP3 using telnet localhost 110 has no errors.
Question #1
Attempting to use squirrel mail brought the frontend error "ERROR: Connection dropped by IMAP server." which I couldn't figure where to check for error log(s). Someone please help. Where do I check to understand this error and fix it?
Question #2
I installed roundcube after squirrel mail failed. I followed the approach at RoundCube Installation. Attempting to login with roundcube shows no frontend error but does not login either. When I survey the roundcube/config/config.inc.php I find only the following basic settings...
$config = array();
$config['db_dsnw'] = 'mysqli://acc:passwd#localhost/roundcube';
$config['default_host'] = 'localhost';
$config['smtp_server'] = 'localhost';
$config['smtp_port'] = 25;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['support_url'] = '';
$config['product_name'] = 'Roundcube Webmail';
$config['des_key'] = 'some_des_key';
$config['plugins'] = array(
'archive',
'zipdownload',
);
$config['skin'] = 'larry';
Are these settings essential for a successful roundcube setup?
Question #3
When I investigate dovecot.conf, which I got after applying the exact steps at Dovecot Installation I see that almost all options and paths are actually commented out, for instance:
base_dir = /var/run/dovecot/
login_dir = /var/run/dovecot/login
login_executable = /usr/local/libexec/dovecot/imap-login
mail_executable = /usr/local/libexec/dovecot/imap
...
login_executable = /usr/local/libexec/dovecot/pop3-login
mail_executable = /usr/local/libexec/dovecot/pop3
auth_socket_path = /var/run/dovecot/auth-master
...
auth_executable = /usr/local/libexec/dovecot/dovecot-auth
...
I haven't tried uncommenting because some like /var/run/dovecot/auth-master do not even seem to exist on my system.
Is this configuration file with such (apparent mistakes) usual and usable?
default: on
# description: mysqlchk
service mysqlchk
{
# this is a config for xinetd, place it in /etc/xinetd.d/
disable = no
flags = REUSE
socket_type = stream
type = UNLISTED
port = 9200
wait = no
user = root
server = /usr/bin/mysqlclustercheck
log_on_failure += USERID
only_from = 0.0.0.0/0
#
# Passing arguments to clustercheck
# <user> <pass> <available_when_donor=0|1> <log_file> <available_when_readonly=0|1> <defaults_extra_file>"
# Recommended: server_args = user pass 1 /var/log/log-file 0 /etc/my.cnf.local"
# Compatibility: server_args = user pass 1 /var/log/log-file 1 /etc/my.cnf.local"
# 55-to-56 upgrade: server_args = user pass 1 /var/log/log-file 0 /etc/my.cnf.extra"
#
# recommended to put the IPs that need
# to connect exclusively (security purposes)
per_source = UNLIMITED
}
/etc/xinetd.d #
It is kind of strange that script works fine when run manually when it runs using /etc/xinetd.d/ , it is not working as expected.
In mysqlclustercheck script, instead of using --user= and passord= syntax, I am using --login-path= syntax
script runs fine when I run using command line but status for xinetd was showing signal 13. After debugging, I have found that even simple command like this is not working
mysql_config_editor print --all >>/tmp/test.txt
We don't see any output generated when it is run using xinetd ( mysqlclustercheck)
Have you tried the following instead of /usr/bin/mysqlclustercheck?
server = /usr/bin/clustercheck
I am wondering if you could test your binary location with the linux which command.
A long time ago since this question was asked, but it just came to my attention.
First of all as mentioned, Percona Cluster Control script is called clustercheck, so make sure you are using the correct name and correct path.
Secondly, since the server script runs fine from command line, it seems to me that the path of mysql client command is not known by the xinetd when it runs the Cluster Control script.
Since the mysqlclustercheck script as it is offered from Percona, it uses only the binary name mysql without specifying the absolute path I suggest you do the following:
Find where mysql client command is located on your system:
ccloud#gal1:~> sudo -i
gal1:~ # which mysql
/usr/local/mysql/bin/mysql
gal1:~ #
then edit script /usr/bin/mysqlclustercheck and in the following line:
MYSQL_CMDLINE="mysql --defaults-extra-file=$DEFAULTS_EXTRA_FILE -nNE --connect-timeout=$TIMEOUT \
place the exact path of mysql client command you found in the previous step.
I also see that you are not using MySQL connection credentials for connecting to MySQL server. mysqlclustercheck script as it is offered from Percona, it uses User/Password in order to connect to MySQL server.
So normally, you should execute the script in the command line like:
gal1:~ # /usr/sbin/clustercheck haproxy haproxyMySQLpass
HTTP/1.1 200 OK
Content-Type: text/plain
Where haproxy/haproxyMySQLpass is the MySQL connection user/pass for HAProxy monitoring user.
Additionally, you should specify them to your script's xinetd settings like:
server = /usr/bin/mysqlclustercheck
server_args = haproxy haproxyMySQLpass
Last but not least, the signal 13 you are getting is because you try to write something in a script run by xinetd. If for example in your mysqlclustercheck you try to add a statement like
echo "debug message"
you probably going to see the broken pipe signal (13 in POSIX).
Finally, I had issues with this script using SLES 12.3 and I finally manage to run it not as 'nobody' but as 'root'.
Hope it helps
OS: Ubuntu 12.04 64-bit
PHP version: 5.4.6-2~precise+1
When I test an https page I am writing through the built-in webserver (php5 -S localhost:8000), Firefox (16.0.1) says "Problem loading: The connection was interrupted", while the terminal tells me "::1:37026 Invalid request (Unsupported SSL request)".
phpinfo() tells me:
Registered Stream Socket Transports: tcp, udp, unix, udg, ssl, sslv3,
tls
[curl] SSL: Yes
SSL Version: OpenSSL/1.0.1
openssl:
OpenSSL support: enabled
OpenSSL Library Version OpenSSL 1.0.1 14 Mar 2012
OpenSSL Header Version OpenSSL 1.0.1 14 Mar 2012
Yes, http pages work just fine.
Any ideas?
See the manual section on the built-in webserver shim:
http://php.net/manual/en/features.commandline.webserver.php
It doesn't support SSL encryption. It's for plain HTTP requests. The openssl extension and function support is unrelated. It does not accept requests or send responses over the stream wrappers.
If you want SSL to run over it, try a stunnel wrapper:
php -S localhost:8000 &
stunnel3 -d 443 -r 8080
It's just for toying anyway.
It's been three years since the last update; here's how I got it working in 2021 on macOS (as an extension to mario's answer):
# Install stunnel
brew install stunnel
# Find the configuration directory
cd /usr/local/etc/stunnel
# Copy the sample conf file to actual conf file
cp stunnel.conf-sample stunnel.conf
# Edit conf
vim stunnel.conf
Modify stunnel.conf so it looks like this:
(all other options can be deleted)
; **************************************************************************
; * Global options *
; **************************************************************************
; Debugging stuff (may be useful for troubleshooting)
; Enable foreground = yes to make stunnel work with Homebrew services
foreground = yes
debug = info
output = /usr/local/var/log/stunnel.log
; **************************************************************************
; * Service definitions (remove all services for inetd mode) *
; **************************************************************************
; ***************************************** Example TLS server mode services
; TLS front-end to a web server
[https]
accept = 443
connect = 8000
cert = /usr/local/etc/stunnel/stunnel.pem
; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
;TIMEOUTclose = 0
This accepts HTTPS / SSL at port 443 and connects to a local webserver running at port 8000, using stunnel's default bogus cert at /usr/local/etc/stunnel/stunnel.pem. Log level is info and log outputs are written to /usr/local/var/log/stunnel.log.
Start stunnel:
brew services start stunnel # Different for Linux
Start the webserver:
php -S localhost:8000
Now you can visit https://localhost:443 to visit your webserver: screenshot
There should be a cert error and you'll have to click through a browser warning but that gets you to the point where you can hit your localhost with HTTPS requests, for development.
I've been learning nginx and Laravel recently, and this error has came up many times. It's hard to diagnose because you need to align nginx with Laravel and also the SSL settings in your operating system at the same time (assuming you are making a self-signed cert).
If you are on Windows, it is even more difficult because you have to fight unix carriage returns when dealing with SSL certs. Sometimes you can go through the steps correctly, but you get ruined by cert validation issues. I find the trick is to make the certs in Ubuntu or Mac and email them to yourself, or use the linux subsystem.
In my case, I kept running into an issue where I declare HTTPS somewhere but php artisan serve only works on HTTP.
I just caused this Invalid request (Unsupported SSL request) error again after SSL was hooked up fine. It turned out to be that I was using Axios to make a POST request to https://. Changing it to POST http:// fixed it.
My recommendation to anyone would be to take a look at where and how HTTP/HTTPS is being used.
The textbook definition is probably something like php artisan serve only works over HTTP but requires underlying SSL layer.
Use Ngrok
Expose your server's port like so:
ngrok http <server port>
Browse with the ngrok's secure public address (the one with https).
Note: Though it works like a charm, it seems an overkill since it requires internet and would appreciate better recommendations.
I have a Cpanel Server.
It send emails correctly expect from 1 domain which hosted on the server , so when I try to send email from that domain using roundcube or Horde I got the errror
SMTP Error (451): Failed to add recipient "recipient#exmple.com" (Temporary local problem - please try later).
does anyone know why and how to fix this?
I found the porblem:
After reviewing the file /var/log/exim_mainlog using
tail -f /var/log/exim_mainlog
I noticed that the error was:
2013-05-29 20:04:28 SMTP connection from [127.0.0.1]:36797 (TCP/IP connection count = 1)
2013-05-29 20:04:28 lowest numbered MX record points to local host: domain.com (while verifying <user#domain.com> from host localhost.localdomain (domain.com) [127.0.0.1]:36797)
2013-05-29 20:04:28 H=localhost.localdomain (domain.com) [127.0.0.1]:36797 sender verify defer for <user#domain.com>: lowest numbered MX record points to local host
2013-05-29 20:04:28 H=localhost.localdomain (domain.com) [127.0.0.1]:36797 F=<user#domain.com> A=dovecot_login:narena temporarily rejected RCPT <recipient#exmple.com>: Could not complete sender verify
2013-05-29 20:04:28 SMTP connection from localhost.localdomain (domain.com) [127.0.0.1]:36797 closed by QUIT
so the main problem was:
lowest numbered MX record points to local host
after couple of search I found the soluation in http://forums.cpanel.net/f5/lowest-numbered-mx-record-points-local-host-73563.html
which was to:
login to WHM and go to Main >> DNS Functions >> Edit MX Entry for the domain
set MX priority to 0 for the related domain and save.
I had the same problem after running a script to fix directory permissions on a cPanel-powered server (CentOS 6.5). I checked the logfile (tail -f /var/log/exim_mainlog) and found this error:
require_files: error for /home/user_name/etc/domain.com: Permission denied
Just ran the following command and the issue was fixed:
chown -R user_name:mail /home/user_name/etc/
Hope this helps someone.
check the the file /var/log/exim_mainlog to see more information about the error
tail -f /var/log/exim_mainlog
while trying to send email
Check your MX Entry in Cpanel, if the existing domain priority is less than or equals to 0, set it to 1. Mine is fixed. Hope it will help you.
Wow, after about an hour of searching and meddling with different files, I'd caution any novice not to venture out editing anything before you have a backup or image if your server, as you can cause irrevocable damage to your server. So many people talking garbage about what you should do or test without any real solution.
Anyways, here's what worked for me:
Real problem: Exim was updated to latest version which has loads of bugs like this issue.
How I fixed my server:
Authenticate to Linux via SSH and run the command lines through which we download and install the old version of EXIM.
Command Line 1: wget https://ca1.dynanode.net/exim-4.93-3.el7.x86_64.rpm
Command Line 2: rpm -Uvh --oldpackage exim-4.93-3.el7.x86_64.rpm
Command Line 3: systemctl restart exim
Command Line 4: Systemctl restart clamd
Command Line 5: systemctl restart spamassassin
Optional: just type "Reboot" to restart your server
The command lines above does the following:
Downloads the old package (I'm sure you can google other sources with this file)
Install the old package without prompt
Restart the Exim service
Restart the Clamd Service (AV)
Restart the spamassassin service (Spam Filter)
Restart outlook or whatever you use for mail client and send an email. Mine works, hope yours do too.