> On Feb 6, 2022, at 4:51 PM, Brian Brombacher <br...@planetunix.net> wrote:
>
>
>
>> On Feb 6, 2022, at 4:32 PM, Mike Fischer <fischer+o...@lavielle.com> wrote:
>>
>>
>>>> Am 06.02.2022 um 21:13 schrieb Brian Brombacher <br...@planetunix.net>:
>>>
>>>>> You can work around it by putting both interfaces in diffrent rdomains,
>>>>> then running two httpd instances, one in rdomain with first IP, second in
>>>>> rdomain with second IP.
>>>>
>>>
>>> This will work. You can use PF rules to cross rdomains if you require.
>>
>> Thanks for that info!
>>
>>
>> rdomains are a new concept for me. From what I currently understand after
>> reading rdomain(4) I don’t get why I would need to run two instances of my
>> service, e.g. httpd(8) to use rdomains? Is a process somehow tied to an
>> rdomain?
>>
>> And while the PF mechanism to cross rdomains might be needed in some setups
>> I don’t see where it would help in my scenario? I want to use my service
>> mainly from outside the host. (Though for local access I would understand
>> the need to configure some PF rules.)
>>
>> I tried the following:
>> Starting state: em0 and em1 each configured for IPv4 and IPv6, the later
>> using autoconf
>> em0:
>> …
>> inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
>> inet6 fe80::20c:29ff:fd9c:4b7%em0 prefixlen 64 scopeid 0x1
>> inet6 2001:db8::20c:29ff:fd9c:4b7 prefixlen 64 autoconf pltime 978 vltime
>> 6912
>> …
>>
>> em1:
>> …
>> inet 192.168.0.20 netmask 0xffffff00 broadcast 192.168.0.255
>> inet6 fe80::20c:29ff:fd9c:4c1%em0 prefixlen 64 scopeid 0x1
>> inet6 2001:db8::20c:29ff:fd9c:4c1 prefixlen 64 autoconf pltime 978 vltime
>> 6912
>> …
>>
>> # netstat -R
>> Rdomain 0
>> Interfaces: lo0 em0 em1 enc0 pflog0
>> Routing table: 0
>>
>> #
>>
>> Change #1:
>>
>> # ifconfig em1 rdomain 1
>>
>> New state:
>> em0: (same as above)
>> …
>> inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
>> inet6 fe80::20c:29ff:fd9c:4b7%em0 prefixlen 64 scopeid 0x1
>> inet6 2001:db8::20c:29ff:fd9c:4b7 prefixlen 64 autoconf pltime 978 vltime
>> 6912
>> …
>>
>> em1: (no IPs)
>> …
>> …
>>
>> # netstat -R
>> Rdomain 0
>> Interfaces: lo0 em0 enc0 pflog0
>> Routing table: 0
>>
>> Rdomain 1
>> Interfaces: em1 lo1
>> Routing table: 1
>>
>> #
>>
>> Change #2: Re-add the IPs:
>> # ifconfig em1 inet 192.168.0.20 netmask 255.255.255.0 broadcast
>> 192.168.0.255
>> # ifconfig em1 inet6 autoconf -temporary -soii
>>
>> New state: IPs on em1 are now set as in the original state, em1 is in
>> rdomain 1.
>>
>> So far so good!
>>
>
> At this point I would reconfigure httpd to use two separate ports (80, 81)
> for each site, or two local IP addresses (::1, ::2, I wouldn’t personally do
> this, I would go multi port), and then use PF rules to forward the (em0) port
> 80 as usual and then (em1) port 80 I would forward to rdomain 0, port 81
> (example port).
>
> All of this is beyond the scope of a normal setup. I would usually just do
> as described by others and rely on hostname rather than IP for httpd to
> process requests. If for some reason this isn’t feasible, I’d be curious why.
>
>From your posts I know why you don’t want to use hostnames. I can see utility
>in using different IPs for different sites if you don’t want to advertise that
>the sites are related by their IP.
>
>>
>> After restarting httpd it failed with message: "parent: send server: Can't
>> assign requested address“ in /var/log messages
>> Ok, so there seems to be a reason for needing another instance of httpd. But
>> how would that work? What would I have to do to get that second instance to
>> listen on IPs from rdomain 1?
>>
>> I have tried setting up a copy of /usr/sbin/httpd (actually a symbolic link
>> using the name /root/bin/httpd_em1) and I have created a new
>> /etc/httpd.2.conf with only the em1 related content. I have also duplicated
>> /etc/rc.d/httpd to /etc/rc.d/httpd_em1 and changed
>> daemon='/root/bin/httpd_em1' (the path to my symbolic link) and
>> daemon_flags="${daemon_flags} -f /etc/httpd.2.conf"
>> No joy! rcctl start httpd_em1 results in the same message in
>> /var/log/messages.
>>
>>
>> Thanks for any pointers you can give me.
>>
>> Mike
>>
>
