Re: puppet and cross-platform password hashes

On Fri, Feb 05, 2016 at 03:48:02PM GMT, Joshua Smith wrote: > On Fri, Feb 05, 2016 at 04:04:47PM +0100, Joerg Jung wrote: > > > On 05 Feb 2016, at 08:33, Peter N. M. Hansteen wrote: > > > > > > I'm assuming I'm not the first to encounter this - > > > > > > the scenario is a group

Re: puppet and cross-platform password hashes

Le 2016-02-05 08:33, Peter N. M. Hansteen a écrit : I'm assuming I'm not the first to encounter this - The interesting part is when we start introducing OpenBSD machines to the mix, and creating users with the password hashes from Linux or Solaris fails, apparently because the hashes are not

Re: puppet and cross-platform password hashes

On 2016-02-05, Solène Rapenne wrote: > Le 2016-02-05 08:33, Peter N. M. Hansteen a écrit : >> I'm assuming I'm not the first to encounter this - >> >> The interesting part is when we start introducing OpenBSD machines to >> the mix, and >> creating users with the password

Re: puppet and cross-platform password hashes

On Fri, Feb 05, 2016 at 04:04:47PM +0100, Joerg Jung wrote: > > On 05 Feb 2016, at 08:33, Peter N. M. Hansteen wrote: > > > > I'm assuming I'm not the first to encounter this - > > > > the scenario is a group of admins who have so far run mainly Linux and some > Solaris, > > and

Re: puppet and cross-platform password hashes

> On 05 Feb 2016, at 08:33, Peter N. M. Hansteen wrote: > > I'm assuming I'm not the first to encounter this - > > the scenario is a group of admins who have so far run mainly Linux and some Solaris, > and who have a fairly well developed Puppet setup for maintaining among other

Re: panic: mtx_enter: locking against myself

Any one from @devs have time to pick it up? This is a new env. , so I have time to investigate. Access can be provided on need bases. //mxb > On 4 feb. 2016, at 15:46, mxb wrote: > > Found it in dmesg buffer: > > Stopped at Debugger+0x9: leave > RUN AT LEAST

Re: panic: mtx_enter: locking against myself

> panic: mtx_enter: locking against myself > Starting stack trace... > panic() at panic+0x10b > mtx_enter() at mtx_enter+0x60 > sofree() at sofree+0xa0 > in_pcbdetach() at in_pcbdetach+0x40 > tcp_close() at tcp_close+0xad > tcp_timer_2msl() at tcp_timer_2msl+0x90 > softclock() at softclock+0x315 >

Re: gnome crashes with current snapshot

> -Oorspronkelijk bericht- > Van: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Namens > Tiemen Werkman > Verzonden: donderdag 4 februari 2016 17:49 > Aan: misc@openbsd.org > Onderwerp: gnome crashes with current snapshot > > >Synopsis:gnome crashes > >Environment: >

Why regexp works different in stock vi vs. vim

I have file where first symbols are tabs: Sally tried really really hard Timmy tried really really really hard Johnny tried really really really really hard When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In vim it finds

Re: Why regexp works different in stock vi vs. vim

On Fri, Feb 5, 2016 at 6:13 PM, Артур Истомин wrote: > When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In > vim it finds tabs. Why? Because \t is a literal t in a standard regular expression. vim uses a different regular expression library that

Re: Why regexp works different in stock vi vs. vim

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ex.1?query=vi ⟨*literal next*⟩Escape the next character from any special meaning. The ⟨literal next⟩ character is usually ⟨control-V⟩. This does the trick for me: /^V On Fri, Feb 5, 2016 at 12:13 PM, Артур

Re: providing users with equal bandwidth

thank you david. i am reading and experimenting around. peter also gave me this very interesting tip about overloading tables and i am researching in my spare time. i will try to create a setup that uses these capability of pf. i also know that pf is very impressive in managing tcp connections,

Re: Cannot Cleanly Exit FVWM / X Windows System

On 02/05/2016 03:41 AM, Dahlberg, David wrote: Am Donnerstag, den 04.02.2016, 16:40 -0500 schrieb Samir Parikh: If you investigate more closely, you will probably find out, that the system still works, just the graphics is fscked up: Try logging in via ssh, or shutting down the system by