Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Discussion about Cancel-Lock support (Russ Allbery)
2. Re: Build system changes (Russ Allbery)
3. Re: NNTPS pointers / NNSP (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Sat, 23 Oct 2021 11:36:47 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> That's a good question.
> We have lots of examples in the newsfeeds sample file, so normally it is
> not too difficult to find out the right syntax for a basic feed.
> Most of the questions come from readers.conf... which has a cleaner syntax!
Yes, this is a fair point! I think the hardest thing for people to
understand about readers.conf is the way it separates authentication from
authorization. As someone who does identity management professionally,
this makes perfect sense to me, but I don't think it matches how people
are thinking when they set up relatively simple servers.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Sat, 23 Oct 2021 11:44:49 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Many thanks to tackle that work!
> For the 2.6 release branch, maybe we could just take Richard's work on #206.
Yes, agreed.
Probably also worth thinking about whether we want to release 2.7 first
with ovsqlite and *then* merge a potentially disruptive build system
change that's likely to expose a bunch of edge cases and random things the
current build system does that I didn't think about.
>> 7. The easy way to implement the special ownership and permission rules
>> for some INN files is to install them with regular permissions and then
>> fix the permissions afterwards with install-exec-hook. That does mean
>> there will be a window where the permissions will be wrong. Does that
>> seem okay?
> If that's the usual way to do it, that seems OK.
There unfortunately isn't a usual way to do this with Automake that I know
of. INN is somewhat unusual that it messes with the permissions on its
executables to try to prevent them from being accidentally run by someone
other than the news user. (I should go look at some setuid programs and
see how they do it. sudo looks like it doesn't use Automake. util-linux
appears to use install-exec-hook for su.)
> Do you use Automake 1.16.3 or later?
> Support for the -S .OLD option has been added to install-sh in Automake
> 1.16.3 (released in November 2020).
Oh, yes (and thank you for doing that work!). What I wasn't sure how to
do was to pass the option to install when using Automake. Maybe it's just
a matter of overriding INSTALL_DATA and INSTALL_EXEC.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Sun, 24 Oct 2021 01:47:46 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers / NNSP
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/20/21 4:40 PM, Grant Taylor wrote:
> I know that is the standard mode of operation.? However I believe there
> are some ... hacks that can be applied on Linux that get extremely
> creative with the routing table and use other skulduggery to fake the IP
> address that INN (et al.) sees.
Success!!! \o/
I'm using a combination of stunnel, iptables connection marking, and
iproute2 policy based routing to provide NNSP such that INN sees the
remote system's real IP address. }:-D
I can now connect to TCP port 433 on my transit news server using
OpenSSL's s_client. -- I even had to change the location that I was
testing from because INN was rejecting the first client system I was
testing from with "502 You have no permission to talk. Goodbye!". When
I test from an IP address that is allowed to connect, I get 200.
> I'll do some more reading and poking with sticks.? I don't know that the
> systems in question have the necessary support installed; kernel
> requirements, policy based routing, etc.
I started with the following blog article.
Link - stunnel transparent proxy to localhost
- https://blog.inf.re/stunnel-transparent-proxy-to-localhost.html
I then adapted it down to the following:
iptables -t filter -A INPUT -s $INN_IP/32 -i lo -p tcp -m tcp --sport
119 -j ACCEPT
iptables -t nat -A OUTPUT -d $INN_IP/32 -o lo -p tcp -m tcp --dport 119
--tcp-flags FIN,SYN,RST,ACK SYN -j CONNMARK --set-xmark 0x1/0xf
iptables -t mangle -A OUTPUT -s $INN_IP/32 -o eth0 -p tcp -m tcp
--sport 119 -m connmark --mark 0x1/0xf -j CONNMARK --restore-mark
--nfmask 0xf --ctmask 0xf
ip rule add fwmark 0x1 lookup 433
ip route add local 0.0.0.0/0 dev eth0 table 433
I did not need to disable the route_localnet protection IP system
controls. Nor did I need to provide similar protection after disabling
route_localnet protection.
The 2nd and 3rd iptables rules above correspond tot he 3rd & 4th rules
on the linked article.
I used iproute2 routing table #433 to correspond with TCP port 433.
This is a convenient / convention and can really be just about any
non-conflicting number.
This is the /server/ side (receiving server) of the connection. I I
believe that I have an idea for the /client/ side (sending server) that
will basically re-use / extend -- I think -- the second iptables rule
above, just targeting / matching the remote servers that I want to use
NNSP with.
> I believe that somewhere I recently read that TCP wrappers was being
> deprecated.? I have no idea where that was.? Perhaps I should search for
> it.? --? Not that deprecation has prevented ifconfig / route / et al.
> from being mainstream utilities some 20 years later.? ;-)
It looks like what I saw was from RHEL / Fedora announcements.
Link - Changes/Deprecate TCP wrappers - Fedora Project Wiki
- https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211024/6f77ed8d/attachment-0001.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 13
********************************************
