Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Kevin Oberman 
On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra 
wrote:

> Kevin Oberman skrev:
> >
> > Clearly the documentation is a bit behind the times. For some time people
> > have used KERNCONF to build multiple kernels, but that was a lucky things
> > that was not officially supported. It just happened to work. Then, with
> > 11.0, it no longer did in many cases sue to changes in the kernel build
> > system. When people complained, there did not seem to be a way to fix
> this
> > without blocking future goals in speeding up and enhancinghte standard
> > kernel build.
> >
> > The result was BUILDKERNELS. It was specifically designed to allow the
> > building of multiple kernels and the appropriate modules. This would
> always
> > take longer and use more disk space, but it would work reliably. Now, bit
> > building a single, local kernel, KERNCONF is the best way, though I
> suspect
> > that it make only a small difference until new capabilities are added
> later
> > in the life of 11.
> >
> > So, while it seems the man pages need to catch up, building multiple
> > kernels should be done with KERNCONF in either make.conf or src.conf and
> > multiple kernels with BUILDKERNELS.
> >
> > This is from my recollection of the discussion thread. I'll admit to
> being
> > too lazy to go find and read all of it. I suspect it was on current@,
> but
> > I'm not even sure of that.
>
> ???
>
> From /usr/src/Makefile.inc1:
>
>1137 .if ${TARGET_ARCH} == "powerpc64"
>1138 KERNCONF?=  GENERIC64
>1139 .else
>1140 KERNCONF?=  GENERIC
>1141 .endif
>[...]
>1149 BUILDKERNELS=
>1150 INSTALLKERNEL=
>1151 .if defined(NO_INSTALLKERNEL)
>1152 # All of the BUILDKERNELS loops start at index 1.
>1153 BUILDKERNELS+= dummy
>1154 .endif
>1155 .for _kernel in ${KERNCONF}
>1156 .if exists(${KERNCONFDIR}/${_kernel})
>1157 BUILDKERNELS+=  ${_kernel}
>1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL)
>1159 INSTALLKERNEL= ${_kernel}
>1160 .endif
>1161 .endif
>1162 .endfor
>
> So setting BUILDKERNELS has no effect.
>
> --
> Herbert
>

I think you miss the significance. BUILDKERNELS only is used to build the
kernels. It is not used by installkernel as installing two kernels does not
make sense. It is ONLY used to build multiple kernels. KERNCONF is still
used to specify the kernel, with attendant modules, to be installed.

I should also mention that, if you want to install a new kernel without
overwriting the old kernel and modules (/boot/kernel.old/), "make
reinstallkernel". It replaces the existing kernel instead of renaming the
kernel directory to kernel.old. I find this very handy, but it is poorly
documented. So, if you want to install GENERIC and not lose your last
working kernel, "make reinstallkernel KERNCONF=GENERIC". That will blow
away the bad kernel and modules and install GENERIC. Note that it does not
touch the /usr/obj directory that PUMPKIN is built in, so PUMPKIN and
similarly be reinstalled.

The man page for src.conf is automatically generated and only lists those
values which are specific to src.conf (WITH_ and WITHOUT_) and describes
its use. It is used as input for system builds and installs but should not
be accessed for any other purpose. make.conf is always read by make with no
regard to what is being made. (N.B. I believe that some people have ignored
this in some ports stuff.) Anything that is put into make.conf may be
placed in src,conf if you only want to have it used when
building/installing the kernel and world.

I'm probably forgetting something, but I hope this explains it a bit.
--
Kevin Oberman, Retired Network Engineer and kid herder
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CVE-2016-7434 NTP

2016-12-12 Thread Michelle Sullivan 

Dimitry Andric wrote:

On 08 Dec 2016, at 06:08, Michelle Sullivan  wrote:

Are we going to get a patch for CVE-2016-7434 on FreeBSD 9.3?

On Nov 22, in r309009, Xin Li merged ntp 4.2.8p9, which fixes this
issue, to stable/9:

https://svnweb.freebsd.org/changeset/base/309009

Unfortunately the commit message did not mention the CVE identifier.  I
can't find any corresponding security advisory either.

-Dimitry




No updates needed to update system to 9.3-RELEASE-p52.
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
[root@gauntlet /]# ntpd --version
ntpd 4.2.8p8-a (1)

So no then...

9.3 is still so-say supported so I'm not talking about -STABLE.

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Herbert J. Skuhra 
Kevin Oberman skrev:
>
> Clearly the documentation is a bit behind the times. For some time people
> have used KERNCONF to build multiple kernels, but that was a lucky things
> that was not officially supported. It just happened to work. Then, with
> 11.0, it no longer did in many cases sue to changes in the kernel build
> system. When people complained, there did not seem to be a way to fix this
> without blocking future goals in speeding up and enhancinghte standard
> kernel build.
> 
> The result was BUILDKERNELS. It was specifically designed to allow the
> building of multiple kernels and the appropriate modules. This would always
> take longer and use more disk space, but it would work reliably. Now, bit
> building a single, local kernel, KERNCONF is the best way, though I suspect
> that it make only a small difference until new capabilities are added later
> in the life of 11.
> 
> So, while it seems the man pages need to catch up, building multiple
> kernels should be done with KERNCONF in either make.conf or src.conf and
> multiple kernels with BUILDKERNELS.
> 
> This is from my recollection of the discussion thread. I'll admit to being
> too lazy to go find and read all of it. I suspect it was on current@, but
> I'm not even sure of that.

???

>From /usr/src/Makefile.inc1:

   1137 .if ${TARGET_ARCH} == "powerpc64"
   1138 KERNCONF?=  GENERIC64
   1139 .else
   1140 KERNCONF?=  GENERIC
   1141 .endif
   [...]
   1149 BUILDKERNELS=
   1150 INSTALLKERNEL=
   1151 .if defined(NO_INSTALLKERNEL)
   1152 # All of the BUILDKERNELS loops start at index 1.
   1153 BUILDKERNELS+= dummy
   1154 .endif
   1155 .for _kernel in ${KERNCONF}
   1156 .if exists(${KERNCONFDIR}/${_kernel})
   1157 BUILDKERNELS+=  ${_kernel}
   1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL)
   1159 INSTALLKERNEL= ${_kernel}
   1160 .endif
   1161 .endif
   1162 .endfor

So setting BUILDKERNELS has no effect.

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Herbert J. Skuhra 
Kevin Oberman skrev:
> 
> On Mon, Dec 12, 2016 at 1:16 AM, tech-lists  wrote:
>> On 12/12/2016 09:07, Thomas Mueller wrote:
>> 
>>> My question is, do you build modules redundantly, or just once?
>>> I don't want to build the same modules more than once.
>>> 
>> 
>> For me - redundantly, I guess. It's not like it takes a lot of time or
>> space on the compiling machine, and I ensure that everything that needs to
>> be built, is built.
>> 
>> PUMPKIN = heavily modified config with all the stuff I don't need stripped
>> out, and a couple of non-default lines.
>> 
>> GENERIC = unmodified kernel that should work if by some chance PUMPKIN
>> doesn't.
>> --
>> J.
> 
> 
> Clearly the documentation is a bit behind the times. For some time people
> have used KERNCONF to build multiple kernels, but that was a lucky things
> that was not officially supported. It just happened to work. Then, with
> 11.0, it no longer did in many cases sue to changes in the kernel build
> system. When people complained, there did not seem to be a way to fix this
> without blocking future goals in speeding up and enhancinghte standard
> kernel build.
> 
> The result was BUILDKERNELS. It was specifically designed to allow the
> building of multiple kernels and the appropriate modules. This would always
> take longer and use more disk space, but it would work reliably. Now, bit
> building a single, local kernel, KERNCONF is the best way, though I suspect
> that it make only a small difference until new capabilities are added later
> in the life of 11.
> 
> So, while it seems the man pages need to catch up, building multiple
> kernels should be done with KERNCONF in either make.conf or src.conf and
> multiple kernels with BUILDKERNELS.

???

>From /usr/src/Makefile.inc1:

   1137 .if ${TARGET_ARCH} == "powerpc64"
   1138 KERNCONF?=  GENERIC64
   1139 .else
   1140 KERNCONF?=  GENERIC
   1141 .endif
   [...]
   1151 .if defined(NO_INSTALLKERNEL)
   1152 # All of the BUILDKERNELS loops start at index 1.
   1153 BUILDKERNELS+= dummy
   1154 .endif
   1155 .for _kernel in ${KERNCONF}
   1156 .if exists(${KERNCONFDIR}/${_kernel})
   1157 BUILDKERNELS+=  ${_kernel}
   1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL)
   1159 INSTALLKERNEL= ${_kernel}
   1160 .endif
   1161 .endif
   1162 .endfor

So setting BUILDKERNELS has no effect.

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Herbert J. Skuhra 
tech-lists skrev:
>  
> Hi,
> 
> Yep I'm sure. The only extra I've added is for
> nvidia-driver. Everything else is a "without" directive. My
> /etc/src.conf looks like this:
> 
> # less src.conf
> PORTS_MODULES=x11/nvidia-driver
> [...]
> This is the error I get when I try to build kernel and world the old way:
> 
> /usr/src # make cleandir && make clean && make buildworld && make
> buildkernel && make installkernel && mergemaster -p
> [...]
> SRC_BASE=/storage/usr/src  OSVERSION=1100506
> WRKDIRPREFIX=/usr/obj/storage/usr/src/sys/PUMPKIN GENERIC make -B clean all
^^^
> env: GENERIC: No such file or directory
> *** Error code 127

PORTS_MODULES does not work if KERNCONF contains multiple kernels:

The problem is obviously in /usr/src/sys/conf/kern.post.mk (line 66):

WRKDIRPREFIX?=  ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Kevin Oberman 
On Mon, Dec 12, 2016 at 1:16 AM, tech-lists  wrote:

> On 12/12/2016 09:07, Thomas Mueller wrote:
>
>> My question is, do you build modules redundantly, or just once?
>> I don't want to build the same modules more than once.
>>
>
> For me - redundantly, I guess. It's not like it takes a lot of time or
> space on the compiling machine, and I ensure that everything that needs to
> be built, is built.
>
> PUMPKIN = heavily modified config with all the stuff I don't need stripped
> out, and a couple of non-default lines.
>
> GENERIC = unmodified kernel that should work if by some chance PUMPKIN
> doesn't.
> --
> J.


Clearly the documentation is a bit behind the times. For some time people
have used KERNCONF to build multiple kernels, but that was a lucky things
that was not officially supported. It just happened to work. Then, with
11.0, it no longer did in many cases sue to changes in the kernel build
system. When people complained, there did not seem to be a way to fix this
without blocking future goals in speeding up and enhancinghte standard
kernel build.

The result was BUILDKERNELS. It was specifically designed to allow the
building of multiple kernels and the appropriate modules. This would always
take longer and use more disk space, but it would work reliably. Now, bit
building a single, local kernel, KERNCONF is the best way, though I suspect
that it make only a small difference until new capabilities are added later
in the life of 11.

So, while it seems the man pages need to catch up, building multiple
kernels should be done with KERNCONF in either make.conf or src.conf and
multiple kernels with BUILDKERNELS.

This is from my recollection of the discussion thread. I'll admit to being
too lazy to go find and read all of it. I suspect it was on current@, but
I'm not even sure of that.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is System V IPC namespace still shared across jails?

2016-12-12 Thread Christian Schwarz 
With the new jail parameters, new namespaces for SysV IPC are possible
on FreeBSD 11.

For those ezjail users, add something like this to the jail's config
after creating it using 'ezjail-admin create':

 export jail_postgres_parameters="sysvmsg=new sysvsem=new sysvshm=new"

Cheers,

  Christian

---

man 8 jail

>  ...
>
>  allow.sysvipc
>   A process within the jail has access to System V IPC
>   primitives.  This is deprecated in favor of the per-
>   module parameters (see below).  When this parameter is
>   set, it is equivalent to setting sysvmsg, sysvsem, and
>   sysvshm all to ``inherit''.
>
>  ...
>
>sysvmsg
>   Allow access to SYSV IPC message primitives.  If set to
>   ``inherit'', all IPC objects on the system are visible to this
>   jail, whether they were created by the jail itself, the base
>   system, or other jails.  If set to ``new'', the jail will have
>   its own key namespace, and can only see the objects that it has
>   created; the system (or parent jail) has access to the jail's
>   objects, but not to its keys.  If set to ``disable'', the jail
>   cannot perform any sysvmsg-related system calls.
>
> sysvsem, sysvshm
>   Allow access to SYSV IPC semaphore and shared memory primitives,
>   in the same manner as sysvmsg.
>
>  ...

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

Is System V IPC namespace still shared across jails?

2016-12-12 Thread Mark Martinec 
Regarding installation of PostgreSQL in a FreeBSD jail, the web hold 
plenty of
warnings/advice that each postgres instance should have a unique UID, 
otherwise

they stumble across each other's feet:

| allow.sysvipc
|   A process within the jail has access to System V IPC primitives. In 
the
| current jail implementation, System V primitives share a single 
namespace
| across the host and jail environments, meaning that processes within a 
jail
| would be able to communicate with (and potentially interfere with) 
processes

| outside of the jail, and in other jails.


Is this still the case in FreeBSD 11.0 ???

I remember hearing rumors that the System V namespace
no longer is (will?) be shared across jails.
(Couldn't find it being mentioned in release notes.)

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread tech-lists 

On 12/12/2016 09:07, Thomas Mueller wrote:

My question is, do you build modules redundantly, or just once?
I don't want to build the same modules more than once.


For me - redundantly, I guess. It's not like it takes a lot of time or 
space on the compiling machine, and I ensure that everything that needs 
to be built, is built.


PUMPKIN = heavily modified config with all the stuff I don't need 
stripped out, and a couple of non-default lines.


GENERIC = unmodified kernel that should work if by some chance PUMPKIN 
doesn't.

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

2016-12-12 Thread Thomas Mueller 
> BUILDKERNELS=PUMPKIN GENERIC

> > to your /etc/src.conf and removing the KERNCONF line from /etc/make.conf
> > before you run it again.  KERNCONF goes on the "make buildkernel" command,
> > not into /etc/make.conf, but should not be necessary at all if /etc/src.conf
> > contains the list of kernels to be built.  (See src.conf(5).)

> - BUILDKERNELS is used in Makefile.inc1 but not listed in neither
>   src.conf(5) nor make.conf(5)
> - KERNCONF is listed in make.conf(5)
> - I use KERNCONF in /etc/make.conf to build two kernels and it works

> So why are you giving this advice?

> Herbert

I would have thought KERNCONF would belong in src.conf, but just checked the 
man pages, and KERNCONF is listed in man make.conf but not src.conf .

I usually build at least two kernels, one being the custom kernel and the other 
being GENERIB.

GENERIB differs from GENERIC in not supporting very outdated devices (ISA SCSI 
cards for instance) but including support from some wi-fi drivers not in 
GENERIC.  I need rsu.

My question is, do you build modules redundantly, or just once?  I don't want 
to build the same modules more than once.

Tom

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