public key-only accounts
This is current/amd64. I created a user account, disabling password logins, and put the guy's public ssh key into his ~/.ssh/authorized_keys The user can log in and everything works, but: Running security(8): Checking the /etc/master.passwd file: Login maxa is off but still has a valid shell and alternate access files in home directory are still readable. According to master.passwd(5) login accounts not allowing password authentication but allowing other authentication methods, for example public key authentication, conventionally have 13 asterisks in the password field. but adduser did not put 13 asterisks in the password field (just '*') and security(8)'s check_passwd() seems to have no notion of '13 asterisks in the password field' - the login is just considered 'off' if $pwd !~ /^\$[0-9a-f]+\$/ Is the info in master.passwd(5) still valid? Should adduser put '*' as the passwd for such accounts? (I do see accounts with 13 asterisks for passwd, e.g. _postgresql.) Jan
Re: kernel_relinking failed
On 11/18/17 15:38, Roderick wrote:
>
> Dear Sirs,
>
> At about every second shutdown I get at the end the message:
>
> ---
> reorder_kernel: kernel relinking failed; see
> /usr/share/compile/GENERIC.MP/relink.org
> ---
>
> The contents of last file is at the end of this Email.
>
> It is a just installed OpenBSD 6.2 (no upgrade). What does this
> error mean?
>
> Thanks
> Rodrigo.
>
>
>
> relink.log
> ---
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> text databss dec hex
> 8222884 2448464 1093632 11764980b384f4
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> mv -f newbsd bsd
> cmp -s bsd /bsd || ln -f /bsd /obsd
> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h
> /var/db/kernel.SHA256 /bsd
>
> Kernel has been relinked and is active on next reboot.
>
> SHA256 (/bsd) =
> 9426f77b6d313f8f5e07ab1d1fc9bde9ef3975ac5b64ed9540cbd3fda9091884
> ---
Looks like you showed us the relink.log file from the successful times,
as that's pretty much saying, "it worked, it's installed", etc.
Can you show us the relink.log when it fails?
Nick.
Re: [www] fix a link
On Mon, Nov 20, 2017 at 10:47:42PM +0100, Julien Steinhauser wrote: > The link is leading to group.8, let it lead to group.5 fixed, thanks
[www] fix a link
The link is leading to group.8, let it lead to group.5 Index: faq/faq10.html === RCS file: /cvs/www/faq/faq10.html,v retrieving revision 1.273 diff -u -p -r1.273 faq10.html --- faq/faq10.html 13 Oct 2017 23:21:43 - 1.273 +++ faq/faq10.html 20 Nov 2017 21:46:41 - @@ -650,7 +650,7 @@ The most common use cases include: For details on selective group inclusion, see -https://man.openbsd.org/group";>group(5). +https://man.openbsd.org/group.5";>group(5).
RE: kernel reordering and config -e
theo wrote: > Hmm... I can't seem to find a patch in there anywhere. I'll read that as 'proposal accepted', and will try and provide a patch soon. --schaafuit.
Re: RE: kernel reordering and config -e
> > If someone wants to solve this fully there have been some proposals > > for keeping track of the instruction sequence, and attempting to > > reapply it upon each relink in the build directory. There just hasn't > > been any scripting changes to do that from anyone, and it isn't on my > > radar as important. > > How about making reorder_kernel do something like: > > $ if test -f /etc/ukc.conf; then
RE: kernel reordering and config -e
theo wrote: > If someone wants to solve this fully there have been some proposals > for keeping track of the instruction sequence, and attempting to > reapply it upon each relink in the build directory. There just hasn't > been any scripting changes to do that from anyone, and it isn't on my > radar as important. How about making reorder_kernel do something like: $ if test -f /etc/ukc.conf; then
Re: kernel reordering and config -e
> On Mon, Nov 20, 2017 at 08:37:43AM +, Roderick wrote: > > > Commenting out the line "/usr/libexec/reorder_kernel &" at the > > end of rc? > > > > I suspect it is not forseen not to benefice of KARL. > > No, actually, if the hash of the kernel is different than expected, the > reorder_kernel aborts and doesn't generate a new one. So you don't need > to do anything explicitly after the config -e to avoid your change being > wiped out. What I did was update the saved hash with one matching my > modified kernel (not quite understanding what was going on yet) which > caused KARL to wipe my changes out with the default. Correct. If you use config -e, you disable KARL. If you disable KARL, the change sticks. But KARL is disabled. If someone wants to solve this fully there have been some proposals for keeping track of the instruction sequence, and attempting to reapply it upon each relink in the build directory. There just hasn't been any scripting changes to do that from anyone, and it isn't on my radar as important.
Re: kernel reordering and config -e
On Mon, Nov 20, 2017 at 08:37:43AM +, Roderick wrote: > Commenting out the line "/usr/libexec/reorder_kernel &" at the > end of rc? > > I suspect it is not forseen not to benefice of KARL. No, actually, if the hash of the kernel is different than expected, the reorder_kernel aborts and doesn't generate a new one. So you don't need to do anything explicitly after the config -e to avoid your change being wiped out. What I did was update the saved hash with one matching my modified kernel (not quite understanding what was going on yet) which caused KARL to wipe my changes out with the default.
Re: 6.2-Release - Firefox and Codeblocks Issues
On 2017-10-16 20:30, Josh Grosse wrote: 1. Discussion was moved to ports@. 2. I have tested a fix, which I will publish for -current and 6.2-stable. 3. I will need to build and test the -stable package, and can then make it available to you if you want to trust an unsigned package from the port maintainer. To close the loop, an improved fix for devel/codeblocks has been submitted to ports@. https://marc.info/?t=15111045484&r=1&w=2
Re: acme-client problem when requesting certificate
> so as far as I understand files get created and right away deleted on > the whole certificate creating process and if I look in /var/www/acme > there isnt any file so what is acme-client telling me with File > exists? Where do I find this file? Whats in your acme-client.conf?
Re: Unsure if I can help update the drivers?
On Fri, 17 Nov 2017 18:50:35 + > > I would like to get a number of intel device IDs and/or drivers > > working with OpenBSD including broxton graphics 0x5a85 > > hmmm, 0x5a85 seems to already be present in the OpenBSD code despite > unknown product except broxton may be being dropped by intel and > apollo lake now uses the broxton code on Linux perhaps with different > firmware. > > Perhaps it is first worth seeing if 4.4.70 and 4.8 linux kernels work > with the apollo lake hardware unless anyone has any insights? Acceleration worked with 4.13 but Ubuntu console even was choppy and unusable even outside of X with 4.4.70 on Ubuntu!!. Turns out xenodm was running and the screen was not being detected on OpenBSD. I'll find out later if Inteldrm works with a native flat panel rather than HDMI but when inteldrm is disabled, wsfb works automatically and rather well even with youtube fullscreen and is more than sufficient for our needs, :).
RE: The "like" factor
"Bryan Harris" wrote: > "My mother had a favorite saying (origin unknown): "You can get used to > anything if you do it long enough. Even hanging." She trotted out that > saying whenever my siblings or I complained about something that wasn't > going to change." > > And later: > > "Persuasion Tip #22: People automatically get used to minor annoyances over > time." > > "My mom's point of view captures an important rule in persuasion. People > can get past minor annoyances if you give them enough time. Humans quickly > adapt to just about anything that doesn't kill them." What Rupert described did not seem to me an annoyance. And define 'adapt to'. Tolerate? Accept? Assimilate? I'll be honest with you: the social engineering approach rather disgusts me. And I happen to know a lot of people who won't fall for it, anyway. On the contrary. They'd be walking out the moment it'd be tried. Overall, I'd advice against this approach. --schaafuit.
Re: The "like" factor
Re: question: > How did you solve the "like" factor? I don't know how true, but I like these passages. "My mother had a favorite saying (origin unknown): "You can get used to anything if you do it long enough. Even hanging." She trotted out that saying whenever my siblings or I complained about something that wasn't going to change." And later: "Persuasion Tip #22: People automatically get used to minor annoyances over time." "My mom’s point of view captures an important rule in persuasion. People can get past minor annoyances if you give them enough time. Humans quickly adapt to just about anything that doesn't kill them." From Win Bigly by Scott Adams V/r, Bryan On Sun, Nov 19, 2017 at 8:25 PM, Rupert Gallagher wrote: > Yes, this may well be the problem: easier to understand if we speak of > teddy bear, much harder if we speak > of software upgrades! And yet, here we are... > > Sent from ProtonMail Mobile > > On Mon, Nov 20, 2017 at 02:17, wrote: > > > I wrote: > > In that case, I'd interpret the beancounter's reponse as > 'have to make > sacrifices, don't we? *sigh*'. I amend that. Isn't it just > loss? We experienced techies try not to allow ourselves to get too attached > to an environment, don't we? But hasn't there been a 'first time' this has > happened, for us all? And were *we* that prepared for it? It's like a > replacement teddy bear, isn't it? The old one might be in pieces and still > the new one won't ever feel as real. Or one's first love. It never quite > feels the same again, does it? Perhaps a shared drink to mark the > transition will help the grieving process along a little. I could still be > all wrong, so I'll just shut up for now and see what others have to say. > --schaafuit. >
acme-client problem when requesting certificate
hi there,
so I set up the acme infrastructure and after some trying I got it
almost to work :)
I had to change the agreement url in the acme-client.conf but now I get
a strange message from acme-client I cant really figure out
acme-client: /var/www/acme/2_e53Y1KM9Tq14dMJuuxMAT8m5gUhxMqD9TntO8ZxbE:
created
acme-client:
https://acme-staging.api.letsencrypt.org/acme/challenge/NY-kkO6QuTWuArFUOhtcilQ0KuotpV41aOwlO9UL9oY/78051622:
challenge
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending",
"uri":
"https://acme-staging.api.letsencrypt.org/acme/challenge/NY-kkO6QuTWuArFUOhtcilQ0KuotpV41aOwlO9UL9oY/78051622";,
"token": "2_e53Y1KM9Tq14dMJuuxMAT8m5gUhxMqD9TntO8ZxbE",
"keyAuthorization":
"2_e53Y1KM9Tq14dMJuuxMAT8m5gUhxMqD9TntO8ZxbE.0s8MYWFs-8TXdp2jx4tPwoDczZpltpon9LGtdsFu0V0"
}] (338 bytes)
acme-client: 2_e53Y1KM9Tq14dMJuuxMAT8m5gUhxMqD9TntO8ZxbE: File exists
acme-client: bad exit: netproc(29731): 1
acme-client: bad exit: challengeproc(50545): 1
so as far as I understand files get created and right away deleted on
the whole certificate creating process and if I look in /var/www/acme
there isnt any file so what is acme-client telling me with File exists?
Where do I find this file?
regards
--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden
http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227
Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
print it, think about your responsibility and commitment to the ENVIRONMENT
RE: kernel reordering and config -e
Hi, "Paul B. Henson" wrote: > Or do you need to update your settings > in the config and compile a kernel from scratch? If you do, does > /usr/share/compile automatically get populated with your new kernel > objects and reordering just starts working, or do you need to do > something manually to get it running with a locally compiled kernel? A hack that might work is to ensure that the config -e is done each time after the reorder, and the checksum updated for the next time 'round. If the power ever goes off between the two passes, though, you'll probably end up with the situation you bumped into now. --schaafuit.
slaacd / dhcp6c
hi i migrate the wwekend my home box from 6.1 to 6.2. all ist working as expected but not the ipv6 "part". under 6.1 i run toghter kernel pppoe with dhcp6v from wide-dhcp6 in a rdomain. i works well , the interface got an ipv6 ip an and an /64 prefix. the same combination is not working anymore ! i got ~ 10>route -n -T 4 exec dhcp6c -f pppoe0 Nov/20/2017 09:37:45: dhcp6_ctl_authinit: failed to open /etc/dhcp6cctlkey: No such file or directory Nov/20/2017 09:37:45: add_options: invalid operation (0) for option type (16) Nov/20/2017 09:37:46: client6_send: transmit failed: No route to host Nov/20/2017 09:37:47: client6_send: transmit failed: No route to host Nov/20/2017 09:37:50: client6_send: transmit failed: No route to host the same with slaacd ~ 11>route -n -T 4 exec slaacd -dv startup start_probe: iface 21: sleeping for 943569usec iface_timeout[21]: IF_DELAY send_solicitation(21) sendmsg: No route to host iface_timeout[21]: IF_PROBE send_solicitation(21) sendmsg: No route to host the pppoe interface is up and running. pppoe0: flags=208851 rdomain 4 mtu 1492 index 21 priority 0 llprio 3 dev: vlan7 state: session sid: 0x83 PADI retries: 6 PADR retries: 0 time: 2d 16:19:42 sppp: phase network authproto pap authname "nc-xxx@" groups: pppoe status: active inet6 fe80::4e02:89ff:fe0d:cb75%pppoe0 -> prefixlen 64 scopeid 0x15 inet 78.34.216.95 --> 195.14.226.22 netmask 0x what wrong ? i dident change anything from 6.1 -> 6.2 holger
Re: kernel reordering and config -e
On Mon, 20 Nov 2017, Sebastien Marie wrote: config -e and KARL (kernel reordering) are mutually incompatibles. [...] So currently, you have to choose between: - modifying /bsd with config(8) and don't benefice of KARL Commenting out the line "/usr/libexec/reorder_kernel &" at the end of rc? I suspect it is not forseen not to benefice of KARL. Rodrigo.
