Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

[Jan Mikkelsen]

> On 13 Jul 2015, at 19:10, Baptiste Daroussin  wrote:
> 
> On Mon, Jul 13, 2015 at 10:36:28AM +0200, Baptiste Daroussin wrote:
>> On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
>>> Hi,
>>> 
>>> In our system build scripts we have this command:
>>> 
>>> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c 
>>> "Bourne-again Superuser" -g wheel -o
>>> 
>>> After 10.2-BETA1, the toor account is being added with UID 1001 instead of 
>>> UID 0. This looks like a problem with line 754 in pw_user.c, which has this 
>>> test:
>>> 
>>>/*
>>> * Check the given uid, if any
>>> */
>>>if (id > 0) {
>>>uid = (uid_t) id;
>>> 
>>>if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
>>>errx(EX_DATAERR, "uid `%u' has already been 
>>> allocated", pwd->pw_uid);
>>>} else {
>>>struct bitmap   bm;
>>> 
>>> 
>>> The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be passed 
>>> on the command line.
>>> 
>>> This change is from r285092 by bapt@. Was this change in behaviour 
>>> intentional?
>> 
>> Nope, I'll fix asap
>> 
>> Thanks for reporting
>> 
>> Best regards,
>> Bapt
> 
> Fixed in head, will be merged soon in stable, I also added a regression test
> about this.
> 
> Please note that you do add -g 0 and -g wheel in your command line, this is
> buggy, only one should be specified.
> 
> Best regards,
> bapt

The next problem is that the meaning of the -o option seems to have been 
reversed. Setting -o sets conf.checkduplicate to true, which is then tested in 
the code fragment above. Setting -o is meant to prevent duplicate checking, not 
turn it on.

My guess is that this isn’t intentional either.

Also: The policy for auto-allocating group identifiers seems to have changed. 
For UIDs < 1000 the old pw allocated a GID the same as the UID. This pw 
allocates the next available above 1000. I can see an argument for both cases 
and I’ve changed our build scripts to deal with this but I’m curious: Was this 
intentional also?

Regards,

Jan.

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

Re: FreeBSD 10.1 Memory Exhaustion

[Shane Ambler]

On 14/07/2015 03:18, Karl Denninger wrote:


The ARC is supposed to auto-size and use all available free memory.  The
problem is that the VM system and ARC system both make assumptions that
under certain load patterns fight with one another, and when this
happens and ARC wins the system gets in trouble FAST.   The pattern is
that the system will start to page RSS out rather than evict ARC, ARC
will fill the freed space, it pages more RSS out. you see where this
winds up heading yes?



Something I noticed was that vfs.zfs.arc_free_target is smaller
than vm.v_free_target

on my desktop with 8GB I get
vfs.zfs.arc_free_target: 14091
vm.v_free_target: 43195

Doesn't that cause arc allocation to trigger swapping leaving space
for arc allocation


--
FreeBSD - the place to B...Storing Data

Shane Ambler

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

Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

[Baptiste Daroussin]

On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
> 
> > On 13 Jul 2015, at 19:10, Baptiste Daroussin  wrote:
> > 
> > On Mon, Jul 13, 2015 at 10:36:28AM +0200, Baptiste Daroussin wrote:
> >> On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
> >>> Hi,
> >>> 
> >>> In our system build scripts we have this command:
> >>> 
> >>> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c 
> >>> "Bourne-again Superuser" -g wheel -o
> >>> 
> >>> After 10.2-BETA1, the toor account is being added with UID 1001 instead 
> >>> of UID 0. This looks like a problem with line 754 in pw_user.c, which has 
> >>> this test:
> >>> 
> >>>/*
> >>> * Check the given uid, if any
> >>> */
> >>>if (id > 0) {
> >>>uid = (uid_t) id;
> >>> 
> >>>if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
> >>>errx(EX_DATAERR, "uid `%u' has already been 
> >>> allocated", pwd->pw_uid);
> >>>} else {
> >>>struct bitmap   bm;
> >>> 
> >>> 
> >>> The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be 
> >>> passed on the command line.
> >>> 
> >>> This change is from r285092 by bapt@. Was this change in behaviour 
> >>> intentional?
> >> 
> >> Nope, I'll fix asap
> >> 
> >> Thanks for reporting
> >> 
> >> Best regards,
> >> Bapt
> > 
> > Fixed in head, will be merged soon in stable, I also added a regression test
> > about this.
> > 
> > Please note that you do add -g 0 and -g wheel in your command line, this is
> > buggy, only one should be specified.
> > 
> > Best regards,
> > bapt
> 
> The next problem is that the meaning of the -o option seems to have been 
> reversed. Setting -o sets conf.checkduplicate to true, which is then tested 
> in the code fragment above. Setting -o is meant to prevent duplicate 
> checking, not turn it on.
> 
> My guess is that this isn’t intentional either.
> 
> Also: The policy for auto-allocating group identifiers seems to have changed. 
> For UIDs < 1000 the old pw allocated a GID the same as the UID. This pw 
> allocates the next available above 1000. I can see an argument for both cases 
> and I’ve changed our build scripts to deal with this but I’m curious: Was 
> this intentional also?
> 

Both has been fixed head already I do plan to merge them later today so they
will be in BETA2

Best regards,
Bapt


pgp6XSYUz1o2z.pgp
Description: PGP signature

Re: FreeBSD 10.1 Memory Exhaustion

[Karl Denninger]

On 7/14/2015 02:49, Shane Ambler wrote:
> On 14/07/2015 03:18, Karl Denninger wrote:
>
>> The ARC is supposed to auto-size and use all available free memory.  The
>> problem is that the VM system and ARC system both make assumptions that
>> under certain load patterns fight with one another, and when this
>> happens and ARC wins the system gets in trouble FAST.   The pattern is
>> that the system will start to page RSS out rather than evict ARC, ARC
>> will fill the freed space, it pages more RSS out. you see where this
>> winds up heading yes?
>>
>
> Something I noticed was that vfs.zfs.arc_free_target is smaller
> than vm.v_free_target
>
> on my desktop with 8GB I get
> vfs.zfs.arc_free_target: 14091
> vm.v_free_target: 43195
>
> Doesn't that cause arc allocation to trigger swapping leaving space
> for arc allocation
>
Yes and no.

On my system with the patch:

vm.v_free_target: 130312
vm.stats.vm.v_free_target: 130312
vfs.zfs.arc_free_target: 86375

and...

[karl@NewFS ~]$ pstat -s
Device  1K-blocks UsedAvail Capacity
/dev/mirror/sw.eli  671088600 67108860 0%

No swapping :-)

It's not busy right now, but this is what the system looks like at the
moment...

1 usersLoad  0.22  0.28  0.32  Jul 14 06:57

Mem:KBREALVIRTUAL   VN PAGER   SWAP
PAGER
Tot   Share  TotShareFree   in   out
in   out
Act 2009856   39980  788450492820  937732  count
All  17499k   52212  8727248   381980  pages
Proc:Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Fltioflt  2638 total
  2 251   1  9264 3332 3982 1134  181 2174   1134 cow  11
uart0 4
  830 zfod   
pcm0 17
 0.4%Sys   0.1%Intr  0.8%User  0.0%Nice 98.8%Idle ozfod  
ehci0 uhci
||||||||||   %ozfod  
uhci1 21
> daefr   508
uhci3 ehci
   dtbuf 1612 prcfr   991
cpu0:timer
Namei Name-cache   Dir-cache485859 desvn 3105 totfr   139
mps0 256
   Callshits   %hits   %161014 numvn  react43
em0:rx 0
71097026  99121460 frevn  pdwak77
em0:tx 0
  459 pdpgs  
em0:link
Disks   da1   da2   da3   da4   da5   da6   da7   intrn   192
em1:rx 0
KB/t   0.00 11.41 10.84 11.68 11.60  0.00  0.00  21089128 wire165
em1:tx 0
tps   021242221 0 0   1153712 act
em1:link
MB/s   0.00  0.23  0.25  0.25  0.24  0.00  0.00   1281556 inact32
cpu1:timer
%busy 0 4 5 5 4 0 0 20372 cache25
cpu9:timer
   916480 free 39
cpu4:timer
  buf  32
cpu13:time
   22
cpu2:timer
   33
cpu11:time
   28
cpu3:timer
   30
cpu14:time
   35
cpu5:timer
   37
cpu12:time
   71
cpu7:timer
   26
cpu10:time
   26
cpu6:timer
   28
cpu8:timer
   48
cpu15:time

Most of that wired memory is in ARC...



ZFS Subsystem ReportTue Jul 14 07:00:29 2015


ARC Summary: (HEALTHY)
Memory Throttle Count:  0

ARC Misc:
Deleted:53.54m
Recycle Misses: 15.12m
Mutex Misses:   6.63k
Evict Skips:275.51m

ARC Size:   75.59%  16.88   GiB
Target Size: (Adaptive) 75.73%  16.91   GiB
Min Size (Hard Limit):  12.50%  2.79GiB
Max Size (High Water):  8:1 22.33   GiB

ARC Size Breakdown:
Recently Used Cache Size:   58.52%  9.89GiB
Frequently Used Cache Size: 41.48%  7.01GiB

ARC Hash Breakdown:
Elements Max:   1.72m
Elements Current: 

Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

[Baptiste Daroussin]

On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
> 
> > On 13 Jul 2015, at 19:10, Baptiste Daroussin  wrote:
> > 
> > On Mon, Jul 13, 2015 at 10:36:28AM +0200, Baptiste Daroussin wrote:
> >> On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
> >>> Hi,
> >>> 
> >>> In our system build scripts we have this command:
> >>> 
> >>> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c 
> >>> "Bourne-again Superuser" -g wheel -o
> >>> 
> >>> After 10.2-BETA1, the toor account is being added with UID 1001 instead 
> >>> of UID 0. This looks like a problem with line 754 in pw_user.c, which has 
> >>> this test:
> >>> 
> >>>/*
> >>> * Check the given uid, if any
> >>> */
> >>>if (id > 0) {
> >>>uid = (uid_t) id;
> >>> 
> >>>if ((pwd = GETPWUID(uid)) != NULL && conf.checkduplicate)
> >>>errx(EX_DATAERR, "uid `%u' has already been 
> >>> allocated", pwd->pw_uid);
> >>>} else {
> >>>struct bitmap   bm;
> >>> 
> >>> 
> >>> The (id > 0) test should probably be (id >= 0) to allow “-u 0” to be 
> >>> passed on the command line.
> >>> 
> >>> This change is from r285092 by bapt@. Was this change in behaviour 
> >>> intentional?
> >> 
> >> Nope, I'll fix asap
> >> 
> >> Thanks for reporting
> >> 
> >> Best regards,
> >> Bapt
> > 
> > Fixed in head, will be merged soon in stable, I also added a regression test
> > about this.
> > 
> > Please note that you do add -g 0 and -g wheel in your command line, this is
> > buggy, only one should be specified.
> > 
> > Best regards,
> > bapt
> 
> The next problem is that the meaning of the -o option seems to have been 
> reversed. Setting -o sets conf.checkduplicate to true, which is then tested 
> in the code fragment above. Setting -o is meant to prevent duplicate 
> checking, not turn it on.
> 
> My guess is that this isn’t intentional either.
> 
> Also: The policy for auto-allocating group identifiers seems to have changed. 
> For UIDs < 1000 the old pw allocated a GID the same as the UID. This pw 
> allocates the next available above 1000. I can see an argument for both cases 
> and I’ve changed our build scripts to deal with this but I’m curious: Was 
> this intentional also?
> 
> Regards,
> 
All fixes has been merged:
https://svnweb.freebsd.org/base?view=revision&revision=285536

Do not hesitate to report other regressions if you do find any more.

Thank you very much,
Bapt


pgpKAZHfAKRVC.pgp
Description: PGP signature

Circular dependency between local_unbound and ntpd?

[Paul Mather]

I believe I ran afoul of a circular dependency between local_unbound and ntpd 
on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use 
ntpd_sync_on_start="YES".

Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch 
for the first time.  No problem, I thought: NTP will correct it at boot.

Wrong!

When my system booted, the time was not corrected.  Also, DNS resolution was 
not working.  I figured out it was because local_unbound relies on an 
accurately set clock, but the clock could not be set accurately because my 
stock ntp.conf requires working DNS resolution to reach the NTP servers.

That sounds like a potential circular dependency to me.

My workaround at the time was to look up 0.freebsd.pool.ntp.org on another 
system; stop ntpd; then do a ntpdate using the IP addresses to set the clock. 
Once the clock was set accurately, things were all hunky dory.

Does anyone have any suggestion for an automatic way around this?  I guess one 
way would be to put the IP address of an NTP server into my ntp.conf file, so 
at least one would be reachable without needing a working DNS?

My main concern is for those systems like my Raspberry Pi and Beaglebone Black 
that don't have a battery-backed clock.  I currently don't use local_unbound on 
those, but it seems like I'd encounter this problem routinely if I did.

Cheers,

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

Re: Circular dependency between local_unbound and ntpd?

[krad]

As

$ grep REQUIRE /etc/rc.d/ntpd
# REQUIRE: DAEMON ntpdate FILESYSTEMS devfs


You could set something similar to the following in the rc.conf

ntpdate_hosts="a.b.c.d w.x.y.z"
ntpdate_enable=yes




On 14 July 2015 at 14:43, Paul Mather  wrote:

> I believe I ran afoul of a circular dependency between local_unbound and
> ntpd on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use
> ntpd_sync_on_start="YES".
>
> Last night, a BIOS settings reset cause my CMOS clock to go WAY out of
> synch for the first time.  No problem, I thought: NTP will correct it at
> boot.
>
> Wrong!
>
> When my system booted, the time was not corrected.  Also, DNS resolution
> was not working.  I figured out it was because local_unbound relies on an
> accurately set clock, but the clock could not be set accurately because my
> stock ntp.conf requires working DNS resolution to reach the NTP servers.
>
> That sounds like a potential circular dependency to me.
>
> My workaround at the time was to look up 0.freebsd.pool.ntp.org on
> another system; stop ntpd; then do a ntpdate using the IP addresses to set
> the clock. Once the clock was set accurately, things were all hunky dory.
>
> Does anyone have any suggestion for an automatic way around this?  I guess
> one way would be to put the IP address of an NTP server into my ntp.conf
> file, so at least one would be reachable without needing a working DNS?
>
> My main concern is for those systems like my Raspberry Pi and Beaglebone
> Black that don't have a battery-backed clock.  I currently don't use
> local_unbound on those, but it seems like I'd encounter this problem
> routinely if I did.
>
> Cheers,
>
> Paul.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Circular dependency between local_unbound and ntpd?

[Paul Mather]

On Jul 14, 2015, at 10:33 AM, krad  wrote:
> 
> As
> 
> $ grep REQUIRE /etc/rc.d/ntpd
> # REQUIRE: DAEMON ntpdate FILESYSTEMS devfs
> 
> 
> You could set something similar to the following in the rc.conf
> 
> ntpdate_hosts="a.b.c.d w.x.y.z"
> ntpdate_enable=yes

Thanks for that suggestion.  I assume the "a.b.c.d w.x.y.z" are IP addresses, 
not hostnames, otherwise we'd have the same problem.

The /etc/rc.d/ntpdate startup script has a "REQUIRE: NETWORKING ..." and 
/etc/rc.d/local_unbound has a "BEFORE: NETWORKING" in it, meaning it will be 
running before ntpdate runs.  That means DNS resolution will require an 
accurate clock and, I assume, mean that ntpdate will require IP addresses, too?

So, it still comes down to this: do I need to know the IP address of an NTP 
server to be able to use local_unbound safely with NTP?

Cheers,

Paul.


> 
> 
> 
> 
> On 14 July 2015 at 14:43, Paul Mather  > wrote:
> I believe I ran afoul of a circular dependency between local_unbound and ntpd 
> on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use 
> ntpd_sync_on_start="YES".
> 
> Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch 
> for the first time.  No problem, I thought: NTP will correct it at boot.
> 
> Wrong!
> 
> When my system booted, the time was not corrected.  Also, DNS resolution was 
> not working.  I figured out it was because local_unbound relies on an 
> accurately set clock, but the clock could not be set accurately because my 
> stock ntp.conf requires working DNS resolution to reach the NTP servers.
> 
> That sounds like a potential circular dependency to me.
> 
> My workaround at the time was to look up 0.freebsd.pool.ntp.org 
>  on another system; stop ntpd; then do a 
> ntpdate using the IP addresses to set the clock. Once the clock was set 
> accurately, things were all hunky dory.
> 
> Does anyone have any suggestion for an automatic way around this?  I guess 
> one way would be to put the IP address of an NTP server into my ntp.conf 
> file, so at least one would be reachable without needing a working DNS?
> 
> My main concern is for those systems like my Raspberry Pi and Beaglebone 
> Black that don't have a battery-backed clock.  I currently don't use 
> local_unbound on those, but it seems like I'd encounter this problem 
> routinely if I did.
> 
> Cheers,
> 
> Paul.
> ___
> freebsd-stable@freebsd.org  mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
> 
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
> "
> 

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

tar: Damaged tar archive, Retrying...

[Nikos Vassiliadis]

Hi,

While trying to create a big tar file containing big files, I got this:

root@m4fh1:/home/nik/peter # tar -cf - . | tar -tf - > /dev/null
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...
tar: Damaged tar archive
tar: Retrying...


The files hierarchy is this:


root@m4fh1:/home/nik/peter # ls -dlh `find .`
drwxr-xr-x  3 root  nik  3B Jul 13 17:16 .
drwxr-xr-x  3 root  nik  4B Jul 14 20:06 ./home
drwxr-xr-x  3 root  nik  3B Jul 13 17:24 ./home/nik
drwxr-xr-x  2 root  nik  4B Jul 13 23:29 ./home/nik/peter
-rw-r--r--  1 nik   nik 60M May 13 19:17 ./home/nik/peter/mysqldump
-rw-r--r--  1 nik   nik 14G May 13 19:39 ./home/nik/peter/vhosts.tar
-rw-r--r--  1 1004  100442G Jul  6 12:39 
./home/the_extremely_serious_backup.tar
root@m4fh1:/home/nik/peter #


This is on 10-STABLE.

Thanks is advance for any ideas!
Nikos

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

Re: Circular dependency between local_unbound and ntpd?

[Charles Sprickman]

On Jul 14, 2015, at 10:47 AM, Paul Mather  wrote:

> On Jul 14, 2015, at 10:33 AM, krad  wrote:
>> 
>> As
>> 
>> $ grep REQUIRE /etc/rc.d/ntpd
>> # REQUIRE: DAEMON ntpdate FILESYSTEMS devfs
>> 
>> 
>> You could set something similar to the following in the rc.conf
>> 
>> ntpdate_hosts="a.b.c.d w.x.y.z"
>> ntpdate_enable=yes
> 
> Thanks for that suggestion.  I assume the "a.b.c.d w.x.y.z" are IP addresses, 
> not hostnames, otherwise we'd have the same problem.
> 
> The /etc/rc.d/ntpdate startup script has a "REQUIRE: NETWORKING ..." and 
> /etc/rc.d/local_unbound has a "BEFORE: NETWORKING" in it, meaning it will be 
> running before ntpdate runs.  That means DNS resolution will require an 
> accurate clock and, I assume, mean that ntpdate will require IP addresses, 
> too?
> 
> So, it still comes down to this: do I need to know the IP address of an NTP 
> server to be able to use local_unbound safely with NTP?

Hopefully not.  I have a client with a number of Mikrotik routers sprinkled 
around upstate.  They did not have an NTP server to point to, so I used a pool 
server.  Mikrotik will take a hostname, but it saves an IP.  A year later I see 
a few not reestablish OpenVPN connections after power failures, spend an hour 
troubleshooting, turns out that those IPs were no longer NTP servers, the box 
thought it was 1970, and that causes the VPN to fail.

TL;DR, don’t save NTP servers by IP in config files.

Charles

> 
> Cheers,
> 
> Paul.
> 
> 
>> 
>> 
>> 
>> 
>> On 14 July 2015 at 14:43, Paul Mather > > wrote:
>> I believe I ran afoul of a circular dependency between local_unbound and 
>> ntpd on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use 
>> ntpd_sync_on_start="YES".
>> 
>> Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch 
>> for the first time.  No problem, I thought: NTP will correct it at boot.
>> 
>> Wrong!
>> 
>> When my system booted, the time was not corrected.  Also, DNS resolution was 
>> not working.  I figured out it was because local_unbound relies on an 
>> accurately set clock, but the clock could not be set accurately because my 
>> stock ntp.conf requires working DNS resolution to reach the NTP servers.
>> 
>> That sounds like a potential circular dependency to me.
>> 
>> My workaround at the time was to look up 0.freebsd.pool.ntp.org 
>>  on another system; stop ntpd; then do a 
>> ntpdate using the IP addresses to set the clock. Once the clock was set 
>> accurately, things were all hunky dory.
>> 
>> Does anyone have any suggestion for an automatic way around this?  I guess 
>> one way would be to put the IP address of an NTP server into my ntp.conf 
>> file, so at least one would be reachable without needing a working DNS?
>> 
>> My main concern is for those systems like my Raspberry Pi and Beaglebone 
>> Black that don't have a battery-backed clock.  I currently don't use 
>> local_unbound on those, but it seems like I'd encounter this problem 
>> routinely if I did.
>> 
>> Cheers,
>> 
>> Paul.
>> ___
>> freebsd-stable@freebsd.org  mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
>> 
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
>> "
>> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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

Re: suspend/resume regression

[Brandon J . Wandersee]

Please forgive me if this seems impudent, but has there been any progress on
this? The status of the bug report hasn't changed since it was opened. I
don't mean to be rude, and I certainly appreciate the effort that's gone
into this already (especially Kevin's detective work), but support for
suspend-to-RAM and my laptop's hotkeys were essentially the only reasons
I started tracking 10-STABLE to begin with. Since both features were
resolved many months ago, I was hoping to switch from -STABLE to 10.2-RELEASE
when it came out, but I'm starting to get the feeling that won't happen
because of a single errant commit. Having to continue following -STABLE
would not be terrible, but it would be disappointing.

-- 
=
  :: Brandon Wandersee ::
  :: brandon.wander...@gmail.com ::
==
'A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.'
- Douglas Adams
==
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ipsec broken again

[Eugene M. Zheganin]

Hi.

As soon as I upgraded one of my ipsec routers to recent stable
(10.2-BETA1 #0 r285524) it stopped working as a security gateway. Ipsec
traffic is passed out and receiving in, SA are in place, but nothing
happens upon receipt (I run gre over ipsec, so gre interface doesn't see
any incoming packets). Last revision I have with ipsec working (probably
not the last in general) was r282461. Could please someone look into this ?

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

Re: ipsec broken again

[Glen Barber]

On Wed, Jul 15, 2015 at 09:42:05AM +0500, Eugene M. Zheganin wrote:
> As soon as I upgraded one of my ipsec routers to recent stable
> (10.2-BETA1 #0 r285524) it stopped working as a security gateway. Ipsec
> traffic is passed out and receiving in, SA are in place, but nothing
> happens upon receipt (I run gre over ipsec, so gre interface doesn't see
> any incoming packets). Last revision I have with ipsec working (probably
> not the last in general) was r282461. Could please someone look into this ?
> 

Please file a PR so this does not get lost.  Add re@ to the CC list, as
well.

Glen



pgpm5ZXftrfTc.pgp
Description: PGP signature