broken source upgrade 9.3-STABLE to 10.3-STABLE

2016-12-13 Thread Eugene Grosbein 
Hi!

I've got legacy FreeBSD server running 8.4-STABLE and I'm trying to upgrade it.
Source upgrade for 8.4 to 9.3-STABLE r310015 went flawlessly.
After reboot, I checked out stable/10 r310043 sources and ran buildworld again.
It fails:

===> lib/clang/libllvmanalysis (all)
c++  -O2 -pipe 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.3\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.3\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" 
-I/usr/obj/usr/src/tmp/legacy/usr/include  -fno-exceptions -fno-rtti -c 
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp
 -o LazyValueInfo.o
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp:
 In member function 'llvm::Constant* 
llvm::LazyValueInfo::getConstant(llvm::Value*, llvm::BasicBlock*)':
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp:1054:
 error: 'nullptr' was not declared in this scope
*** Error code 1

Does it mean that FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 
208032) 20140512
is unable to build more recent clang version?
___
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"

broken source upgrade 9.3-STABLE to 10.3-STABLE

2016-12-13 Thread Eugene Grosbein 
Hi!

I've got legacy FreeBSD server running 8.4-STABLE and I'm trying to upgrade it.
Source upgrade for 8.4 to 9.3-STABLE r310015 went flawlessly.
After reboot, I checked out stable/10 r310043 sources and ran buildworld again.
It fails:

===> lib/clang/libllvmanalysis (all)
c++  -O2 -pipe 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. 
-I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.3\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.3\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" 
-I/usr/obj/usr/src/tmp/legacy/usr/include  -fno-exceptions -fno-rtti -c 
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp
 -o LazyValueInfo.o
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp:
 In member function 'llvm::Constant* 
llvm::LazyValueInfo::getConstant(llvm::Value*, llvm::BasicBlock*)':
/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp:1054:
 error: 'nullptr' was not declared in this scope
*** Error code 1

Does it mean that FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 
208032) 20140512
is unable to build more recent clang version?
___
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: Huge hpet0 interrupt storm, but only if HGST HTS721010A9E630 HDD is present at the boot _and_ formatted with recognized fs (??)

2016-12-13 Thread Jakub Lach 
No change after a # gpart destroy -F , like something permanently changed
after 
first writes to disk.



--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/Huge-hpet0-interrupt-storm-but-only-if-HGST-HTS721010A9E630-HDD-is-present-at-the-boot-and-formatted-tp6151041p6151798.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
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"

The EASIEST CHRISTMAS present for everyone..

2016-12-13 Thread Banana Bed via freebsd-stable 

Your email client cannot read this email.
To view it online, please go here:
http://e.bananabed.com.au/mail/display.php?M=167275=8648afca1a3d942b3722860809266e82=9=2=2


To stop receiving these
emails:http://e.bananabed.com.au/mail/unsubscribe.php?M=167275=8648afca1a3d942b3722860809266e82=2=9
___
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-13 Thread Xin LI 
We plan to issue an EN to update the base system ntp to 4.2.8p9.

The high impact issue is Windows only by the way.

Cheers,

On Mon, Dec 12, 2016 at 6:18 PM, Michelle Sullivan  wrote:
> 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-13 Thread Ian Lepore 
On Tue, 2016-12-13 at 10:13 -0700, Ian Lepore wrote:
> On Tue, 2016-12-13 at 10:00 +, tech-lists wrote:
> > 
> > On 12/12/2016 23:40, Herbert J. Skuhra wrote:
> > > 
> > > 
> > > 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}
> > hmm! I didn't know that.
> > 
> > I can't confirm exactly when the old way stopped working and when
> > I 
> > started defining modules in src.conf.
> > 
> > If I wanted to install a known, good kernel as /boot/workingkernel
> > with 
> > all of its modules, so that I can avoid kernel.old being a bad
> > kernel 
> > and kernel being non-bootable, how would I go about doing it?
> > 
> > many thanks,
> > 
> I think the problem might have started with some changes to the
> kernel
> build infrastructure that result in reading make.conf and/or src.conf
> when they didn't used to, so now KERNCONF with multiple entries is
> defined differently in kern.post.mk than it used to be.
> 
> I wonder if this patch might fix it (I'm not in a position to test it
> myself right now -- this is purely a shot in the dark)...
> 
> iIndex: sys/conf/kern.post.mk
> ===
> --- sys/conf/kern.post.mk (revision 302505)
> +++ sys/conf/kern.post.mk (working copy)
> @@ -63,7 +63,7 @@ OSRELDATE!= awk
> '/^\#define[[:space:]]*__FreeBSD_v
>   ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate
> .h
>  .endif
>  # Keep the related ports builds in the obj directory so that they
> are only rebuilt once per kernel build
> -WRKDIRPREFIX?=   ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
> +WRKDIRPREFIX?=   ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${.OBJDIR}
>  PORTSMODULESENV=\
>   PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
>   SRC_BASE=${SRC_BASE} \
> 
> -- Ian

Actually, now that I look at it again, I wonder if it should be just:

+WRKDIRPREFIX?= ${.OBJDIR}

-- Ian

___
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-13 Thread Ian Lepore 
On Tue, 2016-12-13 at 10:00 +, tech-lists wrote:
> On 12/12/2016 23:40, Herbert J. Skuhra wrote:
> > 
> > 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}
> hmm! I didn't know that.
> 
> I can't confirm exactly when the old way stopped working and when I 
> started defining modules in src.conf.
> 
> If I wanted to install a known, good kernel as /boot/workingkernel
> with 
> all of its modules, so that I can avoid kernel.old being a bad
> kernel 
> and kernel being non-bootable, how would I go about doing it?
> 
> many thanks,
> 

I think the problem might have started with some changes to the kernel
build infrastructure that result in reading make.conf and/or src.conf
when they didn't used to, so now KERNCONF with multiple entries is
defined differently in kern.post.mk than it used to be.

I wonder if this patch might fix it (I'm not in a position to test it
myself right now -- this is purely a shot in the dark)...

iIndex: sys/conf/kern.post.mk
===
--- sys/conf/kern.post.mk   (revision 302505)
+++ sys/conf/kern.post.mk   (working copy)
@@ -63,7 +63,7 @@ OSRELDATE!=   awk '/^\#define[[:space:]]*__FreeBSD_v
    ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate.h
 .endif
 # Keep the related ports builds in the obj directory so that they are only 
rebuilt once per kernel build
-WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
+WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${.OBJDIR}
 PORTSMODULESENV=\
    PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
    SRC_BASE=${SRC_BASE} \

-- Ian

___
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-13 Thread Ian Lepore 
On Mon, 2016-12-12 at 20:22 -0800, Kevin Oberman wrote:
> On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra  rg>
> 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.

The BUILDKERNELS variable is part of the build system's internal
machinery for building multiple kernels when the user has set KERNCONF=
to more than one name.  It's not a thing that a user can set.

-- Ian

___
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-13 Thread Mark Martinec 

2016-12-13 16:29, Alan Somers wrote:

I've already added support for sysvmsg, sysvsem, and sysvshm to
iocage.  They all default to "new", which means you won't have to do
anything special in your jail config to make postgres work.  You can
find the patch below.  The only reason it hasn't been merged is
because it can't (yet) be made to work correctly on the develop branch
of iocage.  But it works fine on the master branch.

https://github.com/iocage/iocage/pull/370

-Alan


Superb, appreciated!

  Mark




On Tue, Dec 13, 2016 at 8:08 AM, Mark Martinec
 wrote:

2016-12-12 20:38, Christian Schwarz wrote:


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



Thank you, this is it!
I missed it in the JAIL(8) man page, and is not mentioned in release 
notes.


Now if only the iocage would recognized the sysvmsg, sysvsem, and 
sysvshm

options:

# iocage set sysvmsg='new' xxx
  ERROR: Unsupported property: sysvmsg!

I guess I should file a bug report.
  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: CVE-2016-7434 NTP

2016-12-13 Thread Dimitry Andric 
On 13 Dec 2016, at 03:18, Michelle Sullivan  wrote:
> 
> 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.
...
> 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.

Well, as I mentioned, there was no Security Advisory (which is a little
strange), so I didn't expect there to be any binary updates.  As far as
I know, binary updates are only built for Security Advisories and Errata
Notices.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

2016-12-13 Thread Alan Somers 
I've already added support for sysvmsg, sysvsem, and sysvshm to
iocage.  They all default to "new", which means you won't have to do
anything special in your jail config to make postgres work.  You can
find the patch below.  The only reason it hasn't been merged is
because it can't (yet) be made to work correctly on the develop branch
of iocage.  But it works fine on the master branch.

https://github.com/iocage/iocage/pull/370

-Alan

On Tue, Dec 13, 2016 at 8:08 AM, Mark Martinec
 wrote:
> 2016-12-12 20:38, Christian Schwarz wrote:
>>
>> 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
>
>
>
> Thank you, this is it!
> I missed it in the JAIL(8) man page, and is not mentioned in release notes.
>
>
> Now if only the iocage would recognized the sysvmsg, sysvsem, and sysvshm
> options:
>
> # iocage set sysvmsg='new' xxx
>   ERROR: Unsupported property: sysvmsg!
>
> I guess I should file a bug report.
>
>
>   Mark
>
>
>
>> 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.
>
>
 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"
___
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-13 Thread Mark Martinec 

2016-12-12 20:38, Christian Schwarz wrote:

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



Thank you, this is it!
I missed it in the JAIL(8) man page, and is not mentioned in release 
notes.



Now if only the iocage would recognized the sysvmsg, sysvsem, and 
sysvshm

options:

# iocage set sysvmsg='new' xxx
  ERROR: Unsupported property: sysvmsg!

I guess I should file a bug report.


  Mark




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.


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-13 Thread tech-lists 

On 12/12/2016 23:40, Herbert J. Skuhra wrote:

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}


hmm! I didn't know that.

I can't confirm exactly when the old way stopped working and when I 
started defining modules in src.conf.


If I wanted to install a known, good kernel as /boot/workingkernel with 
all of its modules, so that I can avoid kernel.old being a bad kernel 
and kernel being non-bootable, how would I go about doing it?


many thanks,

--
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-13 Thread tech-lists 

On 13/12/2016 04:22, Kevin Oberman wrote:

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.


Hi,

Thanks for trying to help - as you say, it's quite poorly documented. 
I'd document it if I had more of as clue what I was doing.


Do you know how to get the process to respect MAKE_JOBS_NUMBER=32 ?

(I mean I'm happy to have to put everything on one line rather than 
setting variables in src.conf or make.conf, it's just that it used to 
work and now does not, so am interested in *The Right Way*(tm) to do 
what I'm trying to do).


Many thanks,
--
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-13 Thread Herbert J. Skuhra 
Kevin Oberman skrev:
> 
> 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.

Sorry, but why are you telling (me) all this? :) Can we return to the
OP's issue? How does setting BUILDKERNELS (as suggested by Scott B.)
resolves (t)his issue? His problem is obviously PORTS_MODULES (see my
previous message).

--
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"