Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

[O. Hartmann]

Am Fri, 09 Feb 2018 16:43:17 +
"Bjoern A. Zeeb"  schrieb:

> On 9 Feb 2018, at 16:22, O. Hartmann wrote:
> 
> > Am Thu, 8 Feb 2018 09:31:15 +0100
> > "O. Hartmann"  schrieb:
> >
> > Is this problem to trivial?  
> 
> I read through it yesterday and found myself in the position that I need 
> a whiteboard or paper and pencil or an ASCII art of your situation.  But 
> by the time I made it to the question I was basically lost.  Could you 
> massively simplify this and maybe produce the ASCII art?
> 
> /bz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

All right.

I'm not much of an artist and at this very moment, I haven't much experience 
with neat
ASCII art tools. But I'll provide a sketch later, but I also will simplify  the 
situation.

Consider three "vswitches", basically based on the creation of bridges, 
bridge0, bridge1,
bridge2. Create at least three individual vnet-jails attached to each vbridge. 
Those
jails have epair pseudo devices. The jail itself owns the "a-part" of the epair 
and the
b-part is "member of the bridge". Each jail's epairXXXa has an IP assigned of 
the network
the vswitch is part of. I mention a- and b-part of the epair here, because I 
thought it
could matter, but I think for symmetry reasons it doesn't.

Now consider a further, special jail. This jail is supposed to have three epair 
devices,
each one is reaching into one of the vbridges. This jail is the router/routing 
jail.
Later, this jail should filter via IPFW the traffic between the three vbridges 
according
to rules, but this doesn't matter here, beacuase the basics are not working as 
expected.

Now the problems. It doesn't matter on which jail of the three vswitches I 
login, the
moment a vbridge has more than two member epairs (one  is alway member of the 
routing
jail, now consider a database jail and a webserver jail), pinging each jail or 
the
routing jail fails. It works sometimes for a couple of ICMP packets and then 
stops.

If each vbridge has only one member jail, I have NO PROBLEMS traversing 
accordingly to
the static routing rules from one vbridge to any other, say from vbridge1 to 
vbridge0 or
vbridge2 and any permutation of that.

The moment any of the bridges gets an additional member epair interface (so the 
bridge
has at least three members including the on reaching into the virtual router 
jail) the
vbridge seems to operate unpredictable (to me). Pinging jails memeber of that 
vbridge
are unreachable.

Technical information:

The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel) declines 
packets by
default. Each jail is configured to have ipfw "open".

Thanks for the patience.

Kind regards,

O. Hartmann


pgpruzqWVMaOU.pgp
Description: OpenPGP digital signature

Re: Makefile and nested variables question

[Bryan Drewery]

On 2/9/2018 9:02 AM, Johannes Lundberg wrote:
> Hi
> 
> Is there some way to use nested variables in the dependency line like so:
> 
> ${OBJS}: ${${.TARGET:S/$/_DEPS/}}
> 
> In my case I get nothing..
> 

I think I need more details. That line won't work. ${.TARGET} is only
defined *in a running target*, not while declaring dependencies.

If these OBJS are C files then this syntax may be enough to only declare
the dependencies when really needed.
  OBJS_DEPEND_GUESS.foo.o += bar.h bar.c
Rather than what I think you tried:
  foo.o_DEPS += bar.h bar.c

If you want them declared always (ignoring .depend files) then just:
  foo.o: bar.h bar.c

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Bryan Drewery]

On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> Hello!
> 
> For some time (about a week) building and installing kernel fails with
> the error "Variable OBJTOP is recursive." when going to build/install
> module from ports.
> 
> Last successful build was at r328426. Next build at r328527 failed and
> still broken at r328649.
> 
> Without PORTS_MODULES building and installing kernel succeeds. Another
> workaround: ignore error and build/install module directly from ports.
> 
> # cat /etc/make.conf
> MALLOC_PRODUCTION=yes
> KERNCONF=GENERIC-NODEBUG GENERIC
> #KERNCONF= GENERIC-NODEBUG
> CPUTYPE?=native
> #PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
> PORTS_MODULES = graphics/drm-next-kmod 
> 
> DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R 
> 
> WITH_DEBUG_PORTS = mail/neomutt
> 
> WITH_CCACHE_BUILD=yes
> CCACHE_DIR=/home/ccache
> 
> #DEVELOPER=yes
> 
> ...
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
> --- kernel.full ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>   text  data   bssdec hex   filename
>   22584632   1376209   474   28709729   0x1b61361   kernel.full
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
> Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
> --- all ---
> ===> Ports module graphics/drm-next-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX
> -u CPP  -u MAKESYSPATH  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys
> PATH=
> SRC_BASE=/usr/src  OSVERSION=1200056
> WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> clean build
> ===>  Cleaning for drm-next-kmod-g20180117
> ===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> ===>  Extracting for drm-next-kmod-g20180117
> => SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> ===>  Patching for drm-next-kmod-g20180117
> ===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
> ===>  Configuring for drm-next-kmod-g20180117
> ===>  Building for drm-next-kmod-g20180117
> ===> drm (all)
> Variable OBJTOP is recursive.

For some reason I cannot recreate this issue.

-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12.0-CURRENT missing timezones

[Warner Losh]

OK. That makes sense again.


I've pushed two changes (r329064 and r329075) which should correct this.

Warner

On Fri, Feb 9, 2018 at 10:28 AM, David Boyd  wrote:

> On Fri, 2018-02-09 at 10:16 -0700, Warner Losh wrote:
>
>
>
> On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh  wrote:
>
>
>
> On Fri, Feb 9, 2018 at 9:56 AM, David Boyd  wrote:
>
> In the most recent images for 12.0-CURRENT
>
> FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz
>
> FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso
>
> FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img
>
> the /usr/share/zoneinfo directory is sparsely populated with
> directories. The only file present is "zone.tab".
>
>
> I think that may be my fault for changing find -s to find | sort, but I
> think I neglected to add sort to ITOOLS to fix it. Building a test now.
>
>
> I am surprised the 0131 is empty, though My change was after that.
>
> Warner
>
>
> Oops. My mistake (cut and paste error). All dates should be 20180208.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12.0-CURRENT missing timezones

[David Boyd]

On Fri, 2018-02-09 at 10:16 -0700, Warner Losh wrote:
> On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh  wrote:
> > On Fri, Feb 9, 2018 at 9:56 AM, David Boyd 
> > wrote:
> > > In the most recent images for 12.0-CURRENT
> > > 
> > > 
> > > 
> > >         FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz
> > > 
> > > 
> > > 
> > >         FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso
> > > 
> > > 
> > > 
> > >         FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img
> > > 
> > > 
> > > 
> > > the /usr/share/zoneinfo directory is sparsely populated with
> > > 
> > > directories. The only file present is "zone.tab".
> > 
> > I think that may be my fault for changing find -s to find | sort,
> > but I think I neglected to add sort to ITOOLS to fix it. Building a
> > test now.
> 
> I am surprised the 0131 is empty, though My change was after
> that.
> 
> Warner

Oops. My mistake (cut and paste error).  All dates should be 20180208.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12.0-CURRENT missing timezones

[Warner Losh]

On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh  wrote:

>
>
> On Fri, Feb 9, 2018 at 9:56 AM, David Boyd  wrote:
>
>> In the most recent images for 12.0-CURRENT
>>
>> FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz
>>
>> FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso
>>
>> FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img
>>
>> the /usr/share/zoneinfo directory is sparsely populated with
>> directories. The only file present is "zone.tab".
>>
>
> I think that may be my fault for changing find -s to find | sort, but I
> think I neglected to add sort to ITOOLS to fix it. Building a test now.
>

I am surprised the 0131 is empty, though My change was after that.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12.0-CURRENT missing timezones

[Warner Losh]

On Fri, Feb 9, 2018 at 9:56 AM, David Boyd  wrote:

> In the most recent images for 12.0-CURRENT
>
> FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz
>
> FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso
>
> FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img
>
> the /usr/share/zoneinfo directory is sparsely populated with
> directories. The only file present is "zone.tab".
>

I think that may be my fault for changing find -s to find | sort, but I
think I neglected to add sort to ITOOLS to fix it. Building a test now.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

12.0-CURRENT missing timezones

[David Boyd]

In the most recent images for 12.0-CURRENT

FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz

FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso

FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img

the /usr/share/zoneinfo directory is sparsely populated with
directories. The only file present is "zone.tab".

Thanks for looking into this.

David Boyd 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Makefile and nested variables question

[Johannes Lundberg]

Hi

Is there some way to use nested variables in the dependency line like so:

${OBJS}: ${${.TARGET:S/$/_DEPS/}}

In my case I get nothing..

Cheers!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

[Bjoern A. Zeeb]

On 9 Feb 2018, at 16:22, O. Hartmann wrote:


Am Thu, 8 Feb 2018 09:31:15 +0100
"O. Hartmann"  schrieb:

Is this problem to trivial?


I read through it yesterday and found myself in the position that I need 
a whiteboard or paper and pencil or an ASCII art of your situation.  But 
by the time I made it to the question I was basically lost.  Could you 
massively simplify this and maybe produce the ASCII art?


/bz
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

[O. Hartmann]

Am Thu, 8 Feb 2018 09:31:15 +0100
"O. Hartmann"  schrieb:

> Hello,
> 
> I fight with the following problem without any kind of success and I need some
> help and/or advice.
> 
> We are running several CURRENT and 11.1-RELENG-p6 boxes. CURRENT is at the 
> most
> recent version as of today.
> 
> VIMAGE is compiled in into all kernels.
> IPFW is compiled into all kernels and is the one and only firewall used.
> On CURRENT, the host's ipfw is set to "OPEN" (using the rc.-scripts so far). 
> By
> convention, I address the host running the kernel by "host".
> 
> Every jail is created/configured with its own "vnet" cloned network stack
> (vnet=new).
> 
> All hosts do have at least three physical NICs. The host itself is supposed to
> be member of the "friendly" network via a dedicated NIC. The two remaining 
> NICs
> are split into fractions belonging to an "hostile" network on which I'd like 
> to
> place exposed jails (for now), and to the "friendly" network, on which also
> jails will be hosted, but via a dedicated NIC.
> 
> Inbetween those two networks, the host will have a third, intermediate,
> network, call it the "service" network.
> 
> The following will be true for ALL jails created, including the host itself:
> 
> net.link.bridge.pfil_member=0
> net.link.bridge.pfil_bridge=0
> net.link.bridge.pfil_onlyip=0
> 
> First, I clone/create three bridge(4) devices, bridge0 (considered to be the
> "glue" between the "service" jails), bridge1 (considered to be the glue 
> between
> the jails on the friednly network side) and bridge2, which is the glue between
> the jails on the hostile side. bridge1 has eth1 as a member, which provides 
> the
> physical access to the friendly network, eth2 is member of bridge2, which
> provides access to the hostile network.
> 
> By convention, when creating epair(4), the a-portion belongs to the jail 
> itself
> and is assigned with an IPv6 address. The b-portion of the epair(4) is member
> of its bridge according to its realm (friendly, service or hostile network). 
> 
> Additionally, there is a special jail, the router, which has three epair(4)
> devices, the b-portion of the epair is member of the appropriate bridge(4) and
> this router jail has static routes assigned, pointing to the appropriate
> epairXXXa that is suppoesd to be the link into the correct bridge/network. 
> IPFW
> is set to open on this jail (for now). On this special
> jail it is set: net.inet.ip.forwarding=1.
> 
> I hope, the topology is clear so far. All epairs or epair endpoints as well as
> the bridges are UP! Double checked this.
> 
> Jails on bridge0 (service net) have IPs in the range 10.10.0.0/24, the
> b-portion of the routing jail's epair is member of bridge0, as described 
> above,
> and the a-portion of the epair has IP 10.10.0.1. Default route on each jeail
> on bridge0 is set to 10.10.0.1 accordingly.
> 
> Consider a similar setup on the other jails on the friendly and hostile
> network, except the fact that their bridges do have a physical NIC to which
> they may have access to a real network.
> 
> The setup might not be ideal and/or applicable for the purpose of separartion
> of networks virtually, but that shouldn't be the subject here. More important
> is that I assume that I haven't understood some essentials, because the setup
> doens't work as expected. Furthermore, it behaves on FreeBSD 11.1-RELENG-p6
> sometimes completely unpredictable - but in that special case, I think I ran
> IPFW on the host as "WORKSTATION" and dynamic rules may play an important role
> here. But focussing on the CURRENT box, the host's IPFW is set to OPEN.
> 
> With jexec -l hostA I gain access to host A on the "service" bridge0 and I
> want to ping its neighbour, hostB, on the same bridge and in the same net. It
> doesn't work! From the routing jail, I CAN NOT ping any host on bridge0. The
> routing jail has these network settings:
> 
> [... routing jail ...]
>  lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet 127.0.0.1 netmask 0xff00 
> groups: lo
> [epair to bridge0 - service net] 
> epair4000a: flags=8843 metric 0 mtu 
> 1500
> options=8
> ether 02:57:d0:00:07:0a
> inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255 
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> groups: epair
> [epair to bridge1, friendly net] 
> epair4001a: flags=8843 metric 0 mtu 
> 1500
> options=8
> ether 02:57:d0:00:09:0a
> inet 192.168.11.1 netmask 0xff00 broadcast 192.168.11.255 
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> groups: epair
> [epair to bridge2, hostile net] 
> epair4002a: flags=8843 metric 0 mtu 
> 1500
> options=8
> ether