OSX 10.13.1
Deployed from algo: master@e01521bbf493d04dd5ffc7942b558d50674b414f
ansible 2.2.0.0
requirements.txtName: msrestazure
Version: 0.4.16
Algo server has sendmail running and accepting connections
Run ./algo in the normal fashion
cloud (digital ocean Ubuntu 16.04)
only the require VPN services should be running
ps aux shows sendmail as running and accepting connections
I closed the window
Steps to reproduce the behavior
Run ./algo in the normal fashion
What options did you choose? We ask these questions because we need them to properly troubleshot.
Which ones were specific to what you needed? I closed the window so I don't know what the logs and options were exactly, but from memory I chose yes to some of the options for connect on demand
I need all of them, thanks.
I see sendmail running on my droplets but the iptables rules prevent it from accepting external connections. I create my droplets like this:
ansible-playbook deploy.yml -t digitalocean,vpn,cloud,dns,security \
-e "do_access_token=$DO_ACCESS_TOKEN do_server_name=$DO_SERVER_NAME do_region=$DO_REGION OnDemandEnabled_WIFI=Y"
I hadn’t checked the Ip tables but I did notice when ssh’ing into the
instance for the first time that I was prompted that I had new mail. I
haven’t read it (the mail client isn’t installed on the machine and I
haven’t had time to dig into the raw file)
On Mon, Nov 20, 2017 at 4:11 AM David Myers notifications@github.com
wrote:
I see sendmail running on my droplets but the iptables rules prevent it
from accepting external connections. I create my droplets like this:ansible-playbook deploy.yml -t digitalocean,vpn,cloud,dns,security \
-e "do_access_token=$DO_ACCESS_TOKEN do_server_name=$DO_SERVER_NAME do_region=$DO_REGION OnDemandEnabled_WIFI=Y"—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/trailofbits/algo/issues/731#issuecomment-345545585,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEV8Q0OTU6Hkh35DRpgE_inwd6aT-QC2ks5s4ItXgaJpZM4Qjeb5
.
If you try telnet <ip_address> smtp it should fail. If you log in to the droplet then telnet localhost smtp will succeed. netstat -plunt will tell you which processes are listening to which ports.
Your mail will be in /var/mail/root. I don't think I've ever gotten any mail on any of the 20 or so Algo droplets I've created.
@davidemyers thanks for the tips! looks like it is indeed blocked externally, but there is the sendmail MTA listening on standard smtp ports.
I took a look at the mail file, and it seems like something happened that prevented the adblock script from being installed properly:
From [email protected] Mon Nov 20 02:10:11 2017
Return-Path: <[email protected]>
Received: from algo.local (localhost [127.0.0.1])
by algo.local (8.15.2/8.15.2/Debian-3) with ESMTP id vAK2ABQj029782
for <[email protected]>; Mon, 20 Nov 2017 02:10:11 GMT
Received: (from root@localhost)
by algo.local (8.15.2/8.15.2/Submit) id vAK2ABdf029781
for root; Mon, 20 Nov 2017 02:10:11 GMT
Date: Mon, 20 Nov 2017 02:10:11 GMT
Message-Id: <[email protected]>
From: [email protected] (Cron Daemon)
To: [email protected]
Subject: Cron <root@algo> /usr/local/sbin/adblock.sh
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Downloading hosts lists...
/usr/local/sbin/adblock.sh: 41: /usr/local/sbin/adblock.sh: service: not found
Looks to me like a bug in adblock.sh. That script should set its own PATH, but since it doesn't it's not finding /usr/sbin/service when it tries to restart dnsmasq to have the block list reloaded.
The reason I've never seen this mail message myself even though I install the Algo DNS Adblocking feature is because I install the feature only to use it as a caching nameserver, so I disable the running of adblock.sh from cron.
Looks like having sendmail running is a good thing in order to catch problems like this.
@davidemyers @bdharrington7 adblock script issue solved in #736