Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #207122 > unrolled thread

Simple Linux to Linux(Debian) email

Back to article view | Back to linux.debian.user

Contents

  Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-08 14:40 +0200
    Re: Simple Linux to Linux(Debian) email Thomas Pircher <thp+debian@p5r.uk> - 2019-04-08 15:20 +0200
      Re: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-08 15:50 +0200
      Re: Simple Linux to Linux(Debian) email Celejar <celejar@gmail.com> - 2019-04-09 01:00 +0200
      RESOLVED: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-11 18:10 +0200
    Re: Simple Linux to Linux(Debian) email Ryan Nowakowski <tubaman@fattuba.com> - 2019-04-08 15:30 +0200
      Re: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-08 15:40 +0200
    Re: Simple Linux to Linux(Debian) email Joe <joe@jretrading.com> - 2019-04-08 15:40 +0200
      Re: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-08 16:40 +0200
    Re: Simple Linux to Linux(Debian) email <tomas@tuxteam.de> - 2019-04-08 17:50 +0200
      Re: Simple Linux to Linux(Debian) email Erik Christiansen <dvalin@internode.on.net> - 2019-04-09 03:50 +0200
    Re: Simple Linux to Linux(Debian) email Jan Claeys <lists@janc.be> - 2019-04-09 02:40 +0200
      Re: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-11 17:50 +0200
        Re: Simple Linux to Linux(Debian) email Greg Wooledge <wooledg@eeg.ccf.org> - 2019-04-11 18:00 +0200
          Re: Simple Linux to Linux(Debian) email Mark Fletcher <mark27q1@gmail.com> - 2019-04-11 18:20 +0200
        Re: Simple Linux to Linux(Debian) email Greg Wooledge <wooledg@eeg.ccf.org> - 2019-04-11 18:10 +0200
          Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-11 18:20 +0200
            Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-12 10:00 +0200
              Re: Simple Linux to Linux(Debian) email Dan Purgert <dan@djph.net> - 2019-04-12 12:10 +0200
                Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-12 12:30 +0200
                  Re: Simple Linux to Linux(Debian) email Dan Purgert <dan@djph.net> - 2019-04-12 13:10 +0200
                  Re: Simple Linux to Linux(Debian) email Dan Ritter <dsr@randomstring.org> - 2019-04-12 14:00 +0200
                    Re: Simple Linux to Linux(Debian) email Gene Heskett <gheskett@shentel.net> - 2019-04-12 14:40 +0200
                      Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-12 15:30 +0200
                        Re: Simple Linux to Linux(Debian) email Dan Purgert <dan@djph.net> - 2019-04-12 17:00 +0200
                    Re: Simple Linux to Linux(Debian) email Celejar <celejar@gmail.com> - 2019-04-12 23:20 +0200
                      Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-13 00:20 +0200
        Re: Simple Linux to Linux(Debian) email mick crane <mick.crane@gmail.com> - 2019-04-11 18:10 +0200
        Re: Simple Linux to Linux(Debian) email Dan Ritter <dsr@randomstring.org> - 2019-04-11 18:20 +0200
        Re: Simple Linux to Linux(Debian) email Jan Claeys <lists@janc.be> - 2019-04-11 19:10 +0200

Page 1 of 2  [1] 2  Next page →

#207122 — Simple Linux to Linux(Debian) email

Hello all

As I wrote this I began to consider this is slightly OT for this list; 
my apologies for not putting OT in the subject line but mutt won't let 
me go back and edit the subject line.

Short version: Is it reasonable to expect a piece of software to exist 
that establishes a direct connection to a "remote" MTA and delivers mail 
there for delivery, without also offering up mail reception 
capabilities? If it is, what would that software be? Or alternatively, 
is there a failsafe way to configure one of the MTAs (I have no strong 
allegiance to any MTA, although the only one I have experience with is 
exim4) such that even if I miss a configuration step it won't be 
contactable from outside? To be clear, I only wish to be able to send 
mail in one direction in this scenario...

The more detailed background:

My ISP has recently developed the unfortunate habit of changing my IP 
address moderately frequently. They're allowed -- I'm cheap so I haven't 
paid for a fixed IP. I'm shortly going to be moving so now really isn't 
a good time to reconsider that position.

They still aren't changing it crazily frequently, but I now run an 
OpenVPN server at home and it is a bit inconvenient when they change my 
home IP and I don't notice before going on a business trip or something.

I'd like to set up an alert that lets me know when my external IP 
address has changed.

The box that is in a position to notice that the IP address has changed 
is on the outer edge of my network connected directly to the internet. 
It runs LFS.

Deeper inside my network, accessible from the LFS box via the VPN, is a 
Debian Stretch machine where I do most of my work.

I've created a very simple script that is capable of parsing the output 
of "ip addr" and comparing the returned ip address for the relevant 
interface to a stored ip address, and thus being able to tell if the IP 
address has changed. What I'd like to do now is make a means for the LFS 
box to be able to notify me of the fact that the external-facing IP 
address has changed. 

My Debian machine runs exim4 and has a reasonably basic setup that 
allows it to accept mails from other machines on the network (although I 
may need to fiddle around with getting mail to come through the VPN) and 
deliver it either locally or using a friendly mail provider as a 
smarthost. I've successfully sent and received mail between this machine 
and a Buster machine on the same network, those two machines can see 
each other without the VPN. The Buster machine was also running exim4.

The LFS machine is, by design, very sparsely configured with only 
software I truly needed installed. I am willing to add software but wish 
to minimise the risk of installing something that opens up 
external-facing vulnerabilities as much as possible. What I'd really 
like is a piece of software that can reach out to my Stretch machine 
through the VPN to present an email for delivery without offering a 
local MTA that, improperly configured, might end up listening to the 
outside world and thus present a security risk.

I've looked at sendmail, postfix and of course exim4, and these are MTAs 
which could certainly do the job but which also present the risk of 
listening to the internet, especially if I do something stupid in the 
configuration which is entirely feasible. And from some basic tests I 
did on my Stretch machine I think the mail command expects there to be a 
local MTA for it to talk to...

My image of an ideal solution is a piece of software that can present 
email to a remote MTA (ie an MTA not on the local machine) for delivery, 
but is not itself an MTA, and certainly has no capability to listen for 
incoming mail.

Thanks in advance

Mark

[toc] | [next] | [standalone]

#207124

Mark Fletcher wrote:
> mutt won't let me go back and edit the subject line.

Hi Mark,

FYI, mutt does allow you to change the Subject line, in the Compose
Menu, just before sending the mail.

> Short version: Is it reasonable to expect a piece of software to exist
> that establishes a direct connection to a "remote" MTA and delivers mail
> there for delivery, without also offering up mail reception
> capabilities?

Yes, have a look at the dma or nullmailer packages.  There used to be
more of these programs in Debian (ssmtp, for example), but on my system
(Buster) only those two seem to have survived.

You could also use one of the big MTAs and configure them to listen to
local connections only, and/or block the SMTP ports with a firewall, but
both dma and nullmailer do their job just fine. Besides, they are much
simpler to configure.

Thomas

[toc] | [prev] | [next] | [standalone]

#207131

On Mon, Apr 08, 2019 at 02:14:33PM +0100, Thomas Pircher wrote:
> Mark Fletcher wrote:
> > mutt won't let me go back and edit the subject line.
> 
> Hi Mark,
> 
> Yes, have a look at the dma or nullmailer packages.  There used to be
> more of these programs in Debian (ssmtp, for example), but on my system
> (Buster) only those two seem to have survived.
> 

Thanks, of those dma looks like a perfect match and nullmailer also 
would work.

> You could also use one of the big MTAs and configure them to listen to
> local connections only, and/or block the SMTP ports with a firewall, but
> both dma and nullmailer do their job just fine. Besides, they are much
> simpler to configure.
> 

Yes, I could -- but I'd feel safer in the presence of my own capacity 
for stupid mistakes using a piece of software that just can't listen for 
mail, in this particular scenario. So dma or nullmailer both fit the 
bill. I will pore over their docs as well as sSMTPs and see what comes 
out the best.

Thanks a lot for your help

Mark

[toc] | [prev] | [next] | [standalone]

#207163

On Mon, 8 Apr 2019 14:14:33 +0100
Thomas Pircher <thp+debian@p5r.uk> wrote:

> Mark Fletcher wrote:
> > mutt won't let me go back and edit the subject line.
> 
> Hi Mark,
> 
> FYI, mutt does allow you to change the Subject line, in the Compose
> Menu, just before sending the mail.
> 
> > Short version: Is it reasonable to expect a piece of software to exist
> > that establishes a direct connection to a "remote" MTA and delivers mail
> > there for delivery, without also offering up mail reception
> > capabilities?
> 
> Yes, have a look at the dma or nullmailer packages.  There used to be
> more of these programs in Debian (ssmtp, for example), but on my system
> (Buster) only those two seem to have survived.
> 
> You could also use one of the big MTAs and configure them to listen to
> local connections only, and/or block the SMTP ports with a firewall, but
> both dma and nullmailer do their job just fine. Besides, they are much
> simpler to configure.

The simplified SMTP agents may be simpler to configure, but their
functionality is lacking. Here are some of the issues I've run into:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917932
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960

I don't remember why I didn't wind up using with nullmailer. I
eventually just gave up and configured postfix.

Celejar

[toc] | [prev] | [next] | [standalone]

#207324 — RESOLVED: Simple Linux to Linux(Debian) email

On Mon, Apr 08, 2019 at 02:14:33PM +0100, Thomas Pircher wrote:
> Mark Fletcher wrote:
> > mutt won't let me go back and edit the subject line.
> 
> Hi Mark,
> 
> > Short version: Is it reasonable to expect a piece of software to exist
> > that establishes a direct connection to a "remote" MTA and delivers mail
> > there for delivery, without also offering up mail reception
> > capabilities?
> 
> Yes, have a look at the dma or nullmailer packages.  There used to be
> more of these programs in Debian (ssmtp, for example), but on my system
> (Buster) only those two seem to have survived.
> 
> You could also use one of the big MTAs and configure them to listen to
> local connections only, and/or block the SMTP ports with a firewall, but
> both dma and nullmailer do their job just fine. Besides, they are much
> simpler to configure.
> 

So this issue is now resolved; in the end I went with the sSMTP package, 
which pretty much seems precisely designed for situations like mine. I'm 
slightly alarmed by its orphan status in Debian, preventing it from 
getting into testing -- if I had more time on my hands I'd sign up to 
maintain it. But it was extremely simple to build and worked perfectly 
on my LFS machine once built.

The only thing I needed to do was add a PREROUTING rule on my Stretch 
machine's iptables configuration because my Stretch machine's exim4 is 
not listening on the VPN interface, and I didn't want to change its 
configuration to make it do so because the VPN isn't always up and I 
don't want exim4 failing to start because the VPN hasn't been started 
when it starts during a reboot. So instead I am re-routing traffic 
coming into the Stretch machine via the VPN on the SMTP port to the 
machine's local physical IP address, where exim4 is listening. By NOT 
mucking around in POSTROUTING with the source address of the packets, 
the source remains the VPN IP address of the client machine, and thus 
replies from exim4 are correctly routed back through the VPN to the 
client. Perfect.

I made confusion for myself by initially trying to set the target 
address to 127.0.0.1 instead of my local physical IP; that didn't work, 
I suspect because the packets then become invalid because they are 
claiming to be local packets but have a source address that is 
off-machine. I contemplated for a few minutes what I'd have to do to 
work around that, and concluded that simply mapping to the physical 
private IP of the machine was cleaner, and allows for different machines 
on the VPN to leverage my Stretch box as a mail relay in the future 
should I have the need to do that (I don't today).

It works perfectly -- and more to the point of this thread, sSMTP was 
extremely simple to compile, is extremely simple to use, and does the 
job perfectly.

Thanks to all who made suggestions. I did also download dma and will 
play around with that for learning's sake, but for now I'm going with 
sSMTP as a solution to this particular problem.

Mark

[toc] | [prev] | [next] | [standalone]

#207125

You might check out sSMTP[1]

[1] https://wiki.debian.org/sSMTP

On Mon, Apr 08, 2019 at 09:33:03PM +0900, Mark Fletcher wrote:
> Hello all
> 
> As I wrote this I began to consider this is slightly OT for this list; 
> my apologies for not putting OT in the subject line but mutt won't let 
> me go back and edit the subject line.
> 
> Short version: Is it reasonable to expect a piece of software to exist 
> that establishes a direct connection to a "remote" MTA and delivers mail 
> there for delivery, without also offering up mail reception 
> capabilities? If it is, what would that software be? Or alternatively, 
> is there a failsafe way to configure one of the MTAs (I have no strong 
> allegiance to any MTA, although the only one I have experience with is 
> exim4) such that even if I miss a configuration step it won't be 
> contactable from outside? To be clear, I only wish to be able to send 
> mail in one direction in this scenario...
> 
> The more detailed background:
> 
> My ISP has recently developed the unfortunate habit of changing my IP 
> address moderately frequently. They're allowed -- I'm cheap so I haven't 
> paid for a fixed IP. I'm shortly going to be moving so now really isn't 
> a good time to reconsider that position.
> 
> They still aren't changing it crazily frequently, but I now run an 
> OpenVPN server at home and it is a bit inconvenient when they change my 
> home IP and I don't notice before going on a business trip or something.
> 
> I'd like to set up an alert that lets me know when my external IP 
> address has changed.
> 
> The box that is in a position to notice that the IP address has changed 
> is on the outer edge of my network connected directly to the internet. 
> It runs LFS.
> 
> Deeper inside my network, accessible from the LFS box via the VPN, is a 
> Debian Stretch machine where I do most of my work.
> 
> I've created a very simple script that is capable of parsing the output 
> of "ip addr" and comparing the returned ip address for the relevant 
> interface to a stored ip address, and thus being able to tell if the IP 
> address has changed. What I'd like to do now is make a means for the LFS 
> box to be able to notify me of the fact that the external-facing IP 
> address has changed. 
> 
> My Debian machine runs exim4 and has a reasonably basic setup that 
> allows it to accept mails from other machines on the network (although I 
> may need to fiddle around with getting mail to come through the VPN) and 
> deliver it either locally or using a friendly mail provider as a 
> smarthost. I've successfully sent and received mail between this machine 
> and a Buster machine on the same network, those two machines can see 
> each other without the VPN. The Buster machine was also running exim4.
> 
> The LFS machine is, by design, very sparsely configured with only 
> software I truly needed installed. I am willing to add software but wish 
> to minimise the risk of installing something that opens up 
> external-facing vulnerabilities as much as possible. What I'd really 
> like is a piece of software that can reach out to my Stretch machine 
> through the VPN to present an email for delivery without offering a 
> local MTA that, improperly configured, might end up listening to the 
> outside world and thus present a security risk.
> 
> I've looked at sendmail, postfix and of course exim4, and these are MTAs 
> which could certainly do the job but which also present the risk of 
> listening to the internet, especially if I do something stupid in the 
> configuration which is entirely feasible. And from some basic tests I 
> did on my Stretch machine I think the mail command expects there to be a 
> local MTA for it to talk to...
> 
> My image of an ideal solution is a piece of software that can present 
> email to a remote MTA (ie an MTA not on the local machine) for delivery, 
> but is not itself an MTA, and certainly has no capability to listen for 
> incoming mail.
> 
> Thanks in advance
> 
> Mark
> 

[toc] | [prev] | [next] | [standalone]

#207129

On Mon, Apr 08, 2019 at 07:54:30AM -0500, Ryan Nowakowski wrote:
> You might check out sSMTP[1]
> 
> [1] https://wiki.debian.org/sSMTP
> 
Thanks, looks like sSMTP will do the job. As was pointed out elsewhere 
in the thread, it seems to have been dropped from Buster, but that is no 
barrier for me as I can build it myself on the LFS machine.

Thanks a lot

Mark

[toc] | [prev] | [next] | [standalone]

#207128

On Mon, 8 Apr 2019 21:33:03 +0900
Mark Fletcher <mark27q1@gmail.com> wrote:


> 
> My image of an ideal solution is a piece of software that can present 
> email to a remote MTA (ie an MTA not on the local machine) for
> delivery, but is not itself an MTA, and certainly has no capability
> to listen for incoming mail.
> 

a) Sendmail. Not the full-featured MTA, but the utility.
https://clients.javapipe.com/knowledgebase/132/How-to-Test-Sendmail-From-Command-Line-on-Linux.html

b) Write it yourself. If you can do simple scripting then you can write
something that talks basic SMTP to a remote SMTP server.

Here's basic unencrypted SMTP:
https://my.esecuredata.com/index.php?/knowledgebase/article/112/test-your-smtp-mail-server-via-telnet

There are many similar sites, some going into more detail including how
to find out the recipient's MX server if you don't know already.
https://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/

Other sites explain how to use authenticated SMTP and TLS. If you later
get a fixed IP address and want to run your own mail server, you can
test it for relaying using the telnet technique. Or rely on numerous
websites...

c) Use a standard MTA and tell it not to listen to anything from
outside your network. Use your firewall to not accept SMTP on the WAN
port, and unless you have previously received email directly then the
SMTP port shouldn't be open anyway. 

Use the MTA's configuration to listen only to localhost. Restart it and
check where it's listening with netstat -tpan as root. 

That way you have two mechanisms to prevent access, even if you
misconfigure one of them you should still be OK. After you have the MTA
running and sending email where you want it to go, use ShieldsUp!! on
https://grc.com to check which ports are open to the outside. Select
'All Service Ports' to check TCP/1-1055.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#207137

On Mon, Apr 08, 2019 at 02:39:35PM +0100, Joe wrote:
> On Mon, 8 Apr 2019 21:33:03 +0900
> Mark Fletcher <mark27q1@gmail.com> wrote:
> 
> 
> > 
> > My image of an ideal solution is a piece of software that can present 
> > email to a remote MTA (ie an MTA not on the local machine) for
> > delivery, but is not itself an MTA, and certainly has no capability
> > to listen for incoming mail.
> > 
> 
> a) Sendmail. Not the full-featured MTA, but the utility.
> https://clients.javapipe.com/knowledgebase/132/How-to-Test-Sendmail-From-Command-Line-on-Linux.html
> 

Oh ah. Right, I hadn't separated the two in my mind. This may also do 
the job well I'm guessing.

> b) Write it yourself. If you can do simple scripting then you can write
> something that talks basic SMTP to a remote SMTP server.
> 
> Here's basic unencrypted SMTP:
> https://my.esecuredata.com/index.php?/knowledgebase/article/112/test-your-smtp-mail-server-via-telnet
> 

<snip>

Yes, I had considered that too, and was going to script something up 
over a telnet session (inside my home LAN, albeit through a VPN to be 
able to tunnel back through a NAT'ing router) if this thread didn't turn 
up anything useful. But it did. :)

Also, I'm an engineer by training and follow the principle of re-use -- 
if there's a tool out there that does what I want I'd rather use it than 
write a new one. I admit I sometimes stray from that in the name of 
learning, but on this occasion I just want to solve a problem and move 
on.

> 
> c) Use a standard MTA and tell it not to listen to anything from
> outside your network. Use your firewall to not accept SMTP on the WAN
> port, and unless you have previously received email directly then the
> SMTP port shouldn't be open anyway. 
> 
> Use the MTA's configuration to listen only to localhost. Restart it and
> check where it's listening with netstat -tpan as root. 
> 
> That way you have two mechanisms to prevent access, even if you
> misconfigure one of them you should still be OK. After you have the MTA
> running and sending email where you want it to go, use ShieldsUp!! on
> https://grc.com to check which ports are open to the outside. Select
> 'All Service Ports' to check TCP/1-1055.
> 

Yes, agreed, this should also work. One thing I didn't mention in my 
original post is that I have to build all software for the "client" 
machine from scratch, and I'd expect a full-strength MTA to be a large 
project to build from source (many and potentially complex dependencies 
and so on), while a simple tool is likely to have a smaller and less 
complex dependency tree. Also because security is important on this box, 
every package I add needs careful consideration to make sure it doesn't 
compromise that -- again nudging me towards the smaller, simpler tool 
with fewer dependencies.

Thanks for your suggestions.

Mark

[toc] | [prev] | [next] | [standalone]

#207140

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 08, 2019 at 09:33:03PM +0900, Mark Fletcher wrote:
> Hello all
> 
> As I wrote this I began to consider this is slightly OT for this list; 
> my apologies for not putting OT in the subject line but mutt won't let 
> me go back and edit the subject line.

Mutt can do that, too. To send via an alternative SMTP server, I do
roughly:

  source ~/.muttrc
  set smtp_url="smtp://USER:PASS@your.smtp.server:587"
  set from="tomas zerolo <tomas@smtp.server>"

and put it in ~/.muttrc.otherserver. Then I invoke mutt with

  mutt -F .muttrc.otherserver

and mutt tries to deliver to that other server.

Substitute USER, PASS and your.smtp.server (and the "set from", if
necessary) with appropriate values.

I've assumed you deliver via the SMTP submission port, 587, as is
usual -- substitute that part if not.

About editing the subject: as others have said, as long as you haven't
sent the mail, you can edit the subject (actually all of the mail
headers). I like to have in my .muttrc:

  set edit_headers    # let me edit the message header when composing

so I have the headers at the top of my mail text, separated
by an empty line. Much more convenient :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#207166

On 08.04.19 17:43, tomas@tuxteam.de wrote:
> On Mon, Apr 08, 2019 at 09:33:03PM +0900, Mark Fletcher wrote:
> > Hello all
> > 
> > As I wrote this I began to consider this is slightly OT for this list; 
> > my apologies for not putting OT in the subject line but mutt won't let 
> > me go back and edit the subject line.

As already mentioned, mutt allows editing of the headers prior to
sending. 's' invokes editing of the Subject.

> Mutt can do that, too. To send via an alternative SMTP server, I do
> roughly:
...

That seems very convenient for a mutterer, yet (out of ancient habit) I
use mailx to fling off a quick short missive constructed on the command
line, here any calendar events looming in the next fortnight:

x=`calendar -l 14 -f ~/Personal/calendar`
( [ -n "$x" ] && echo "$x" | mail -s "$x" erik )

(Yes, popular bash idiom has recently (maybe even this century) morphed
from backquotes to $(...) gumpf. \Whatever/ )

You may want to put something other than the first line of the script
output in the subject line, -s "...".

$ apt-cache search mailx | grep mailx
bsd-mailx - simple mail user agent
heirloom-mailx - feature-rich BSD mail(1)

Even more manual would be to employ netcat or telnet to port 25, and
talk raw SMTP. (Handy when diagnosing a remote mailhost's
peculiarities.)

Erik

[toc] | [prev] | [next] | [standalone]

#207165

On Mon, 2019-04-08 at 21:33 +0900, Mark Fletcher wrote:
> I've created a very simple script that is capable of parsing the
> output of "ip addr" and comparing the returned ip address for the
> relevant interface to a stored ip address, and thus being able to
> tell if the IP address has changed. What I'd like to do now is make a
> means for the LFS box to be able to notify me of the fact that the
> external-facing IP address has changed. 

Why not use a dynamic DNS provider?


-- 
Jan Claeys

(please don't CC me when replying to the list)

[toc] | [prev] | [next] | [standalone]

#207321

On Tue, Apr 09, 2019 at 02:34:30AM +0200, Jan Claeys wrote:
> On Mon, 2019-04-08 at 21:33 +0900, Mark Fletcher wrote:
> > I've created a very simple script that is capable of parsing the
> > output of "ip addr" and comparing the returned ip address for the
> > relevant interface to a stored ip address, and thus being able to
> > tell if the IP address has changed. What I'd like to do now is make a
> > means for the LFS box to be able to notify me of the fact that the
> > external-facing IP address has changed. 
> 
> Why not use a dynamic DNS provider?
> 
> 
Primarily because it wouldn't solve my problem. IIUC it would allow me 
to map a domain name to the IP address assigned to my home internet 
connection. That means that when the IP address assigned to my internet 
connection changes, I can simply alter the mapping and my VPN clients 
start working again, without any configuration change on them. Great, 
but that isn't the problem. The problem is how I know that the IP 
address has changed and hence the DNS mapping needs updating. I don't 
see any way that a dynamic DNS service is going to know when my ISP 
arbitrarily re-assigns my IP. I need the machine that is being assigned 
the IP address to be able to tell me when it changes, and that is what 
this thread was about (specifically the "how it would be able to tell 
me" -- I'd figured out the "how it would know" for myself).

But thanks for trying to help anyway!

Mark

[toc] | [prev] | [next] | [standalone]

#207322

On Fri, Apr 12, 2019 at 12:42:12AM +0900, Mark Fletcher wrote:
> > Why not use a dynamic DNS provider?

> The problem is how I know that the IP 
> address has changed and hence the DNS mapping needs updating.

By doing it correctly.

<https://mywiki.wooledge.org/IpAddress> has an example for Debian.
Specifically Debian 8 (jessie), but it should still work in newer
releases.

[toc] | [prev] | [next] | [standalone]

#207327

On Thu, Apr 11, 2019 at 11:51:44AM -0400, Greg Wooledge wrote:
> On Fri, Apr 12, 2019 at 12:42:12AM +0900, Mark Fletcher wrote:
> > > Why not use a dynamic DNS provider?
> 
> > The problem is how I know that the IP 
> > address has changed and hence the DNS mapping needs updating.
> 
> By doing it correctly.
> 
> <https://mywiki.wooledge.org/IpAddress> has an example for Debian.
> Specifically Debian 8 (jessie), but it should still work in newer
> releases.
> 
That page seems to be all about detecting the IP address; thanks, but 
that part was solved before I even opened this thread. Perhaps I phrased 
poorly earlier in the thread. The issue isn't how I tell what my IP 
address is, the issue is how the machine communicates the fact that it 
has changed to me even when I'm not logged into it. And this thread 
solved that.

You did say one very interesting thing that brought me up short on that 
page though; "I need to get my IP address so I can communicate it to my 
dynamic DNS provider" <paraphrasing>. I guess I need to look into that 
-- if that could be automated, then yes a dynamic DNS provider would be 
another, more automated, way to solve my underlying problem (to which I 
now have a solution I'm happy with)

Thanks

Mark

[toc] | [prev] | [next] | [standalone]

#207323

On Thu, Apr 11, 2019 at 05:02:46PM +0100, mick crane wrote:
> I think that is what dynamic ip address services do, change the ipaddress
> but the service has to be on the ISP's router ?
> Do I understand correctly then when your isp/home address changes your box
> broadcasts its domain new address to the internet ?

It doesn't have to be on the router.  You can set up a hook in Debian
to run an arbitrary command whenever your IP address is changed by DHCP.
This hook receives the old and new IP addresses, and some other things,
as environment variables.  It's about 3 lines of code to set it up.  No
parsing of the output of any ip or ifconfig command is needed.

https://mywiki.wooledge.org/IpAddress

[toc] | [prev] | [next] | [standalone]

#207326

On 2019-04-11 17:05, Greg Wooledge wrote:
> On Thu, Apr 11, 2019 at 05:02:46PM +0100, mick crane wrote:
>> I think that is what dynamic ip address services do, change the 
>> ipaddress
>> but the service has to be on the ISP's router ?
>> Do I understand correctly then when your isp/home address changes your 
>> box
>> broadcasts its domain new address to the internet ?
> 
> It doesn't have to be on the router.  You can set up a hook in Debian
> to run an arbitrary command whenever your IP address is changed by 
> DHCP.
> This hook receives the old and new IP addresses, and some other things,
> as environment variables.  It's about 3 lines of code to set it up.  No
> parsing of the output of any ip or ifconfig command is needed.
> 
> https://mywiki.wooledge.org/IpAddress

I'll have a read but there must be something I don't understand.
Thought there was a hierarchy of domain names mapped to ipaddresses that 
all the different servers can query as to where something is.
mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#207356

On 2019-04-11 17:16, mick crane wrote:
> On 2019-04-11 17:05, Greg Wooledge wrote:
>> On Thu, Apr 11, 2019 at 05:02:46PM +0100, mick crane wrote:
>>> I think that is what dynamic ip address services do, change the 
>>> ipaddress
>>> but the service has to be on the ISP's router ?
>>> Do I understand correctly then when your isp/home address changes 
>>> your box
>>> broadcasts its domain new address to the internet ?
>> 
>> It doesn't have to be on the router.  You can set up a hook in Debian
>> to run an arbitrary command whenever your IP address is changed by 
>> DHCP.
>> This hook receives the old and new IP addresses, and some other 
>> things,
>> as environment variables.  It's about 3 lines of code to set it up.  
>> No
>> parsing of the output of any ip or ifconfig command is needed.
>> 
>> https://mywiki.wooledge.org/IpAddress
> 
> I'll have a read but there must be something I don't understand.
> Thought there was a hierarchy of domain names mapped to ipaddresses
> that all the different servers can query as to where something is.

Ok I think I see, you can host your own domain if you have a fixed 
ipaddress but if have ipaddress that changes need to register domain 
name and have company host it and advertise they know where it is but 
can change the nameservers for the domain from theirs to yours at 
changed ipaddress.
You can't willy nilly broadcast any domain to the internet yourself.





> mick

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#207366

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

mick crane wrote:
> On 2019-04-11 17:16, mick crane wrote:
>> On 2019-04-11 17:05, Greg Wooledge wrote:
>>> On Thu, Apr 11, 2019 at 05:02:46PM +0100, mick crane wrote:
>>>> I think that is what dynamic ip address services do, change the 
>>>> ipaddress
>>>> but the service has to be on the ISP's router ?
>>>> Do I understand correctly then when your isp/home address changes 
>>>> your box
>>>> broadcasts its domain new address to the internet ?
>>> 
>>> It doesn't have to be on the router.  You can set up a hook in Debian
>>> to run an arbitrary command whenever your IP address is changed by 
>>> DHCP.
>>> This hook receives the old and new IP addresses, and some other 
>>> things,
>>> as environment variables.  It's about 3 lines of code to set it up.  
>>> No
>>> parsing of the output of any ip or ifconfig command is needed.
>>> 
>>> https://mywiki.wooledge.org/IpAddress
>> 
>> I'll have a read but there must be something I don't understand.
>> Thought there was a hierarchy of domain names mapped to ipaddresses
>> that all the different servers can query as to where something is.
>
> Ok I think I see, you can host your own domain if you have a fixed 
> ipaddress but if have ipaddress that changes need to register domain 
> name and have company host it and advertise they know where it is but 
> can change the nameservers for the domain from theirs to yours at 
> changed ipaddress.
> You can't willy nilly broadcast any domain to the internet yourself.

Well, once your domain is registered (for example, mine), you can either


  1. give your registrar the IP address they should point the domain to.
      This is easiest with static IP address assignments from your ISP, 
      but there's no reason you couldn't do it on a dynamic IP

  OR

  2. Use a dynamic DNS provider (e.g. dyndns, no-ip, afraid, many
      others), and have them automatically update the DNS registration
      when your IP address changes.  

Note that for option 2, you tell your registrar to use those other
nameservers, rather than their own.

I use option 2 myself, registered via ... oh I think 1&1 ... but using
no-ip to provide my dyndns (although the IP hasn't changed in well over
a year - I still don't want to be caught unawares :) )


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlywYO8ACgkQjhHd8xJ5
ooHseAf9EDq3TrI/7tgMnIjaoRbRqXt3UvqpBHMQWY1jbx67SRZm6pe5vYrdMbEC
l56pAdxCGN+m+hbk9+ND+NYhbesm984ySiEciKyKS3Qi06Z0BvZNvEiSQg28BbKU
9c0NFv3a+5lt5WiCsH8W5lZpgY6M3yKlTTOb6b/hZzQYTRUNmr8VpyMh93z8b+je
on7ZmmaGM/6u2ZzlmBzs2liGS4Gf/aBn6sWjxm8w/l+dM5ImMa6RbgOGHZajGfSz
eSFAfKP5gpRDysegflJC4JMS+WFOoZWbnbiomEI8JJAUHCC75YQhZfV43BPiJeiz
PhMSbcbwyUSGB+84emLtbPSrPFBKzw==
=tKhq
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#207368

On 2019-04-12 10:57, Dan Purgert wrote:
> mick crane wrote:
>> On 2019-04-11 17:16, mick crane wrote:
>>> On 2019-04-11 17:05, Greg Wooledge wrote:
>>>> On Thu, Apr 11, 2019 at 05:02:46PM +0100, mick crane wrote:
>>>>> I think that is what dynamic ip address services do, change the
>>>>> ipaddress
>>>>> but the service has to be on the ISP's router ?
>>>>> Do I understand correctly then when your isp/home address changes
>>>>> your box
>>>>> broadcasts its domain new address to the internet ?
>>>> 
>>>> It doesn't have to be on the router.  You can set up a hook in 
>>>> Debian
>>>> to run an arbitrary command whenever your IP address is changed by
>>>> DHCP.
>>>> This hook receives the old and new IP addresses, and some other
>>>> things,
>>>> as environment variables.  It's about 3 lines of code to set it up.
>>>> No
>>>> parsing of the output of any ip or ifconfig command is needed.
>>>> 
>>>> https://mywiki.wooledge.org/IpAddress
>>> 
>>> I'll have a read but there must be something I don't understand.
>>> Thought there was a hierarchy of domain names mapped to ipaddresses
>>> that all the different servers can query as to where something is.
>> 
>> Ok I think I see, you can host your own domain if you have a fixed
>> ipaddress but if have ipaddress that changes need to register domain
>> name and have company host it and advertise they know where it is but
>> can change the nameservers for the domain from theirs to yours at
>> changed ipaddress.
>> You can't willy nilly broadcast any domain to the internet yourself.
> 
> Well, once your domain is registered (for example, mine), you can 
> either
> 
> 
>   1. give your registrar the IP address they should point the domain 
> to.
>       This is easiest with static IP address assignments from your ISP,
>       but there's no reason you couldn't do it on a dynamic IP
> 
>   OR
> 
>   2. Use a dynamic DNS provider (e.g. dyndns, no-ip, afraid, many
>       others), and have them automatically update the DNS registration
>       when your IP address changes.
> 
> Note that for option 2, you tell your registrar to use those other
> nameservers, rather than their own.
> 
> I use option 2 myself, registered via ... oh I think 1&1 ... but using
> no-ip to provide my dyndns (although the IP hasn't changed in well over
> a year - I still don't want to be caught unawares :) )

I thought those dynamic dns services offered a sub domain of their own 
domains.
Can you have any registered domain point to dynamic dns servers and them 
redirect it ?
I have wondered what they do to stop people broadcasting their own top 
level domain.
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web