Re: Ansible install Re: Reboot and re-link (ignore previously sent message)
[Please ignore the previous message I sent on this topic. I
accidentally pressed 'Send' before my message was complete.]
On 22/06/2019 19:52, cho...@jtan.com wrote:
> Lyndon Nerenberg writes:
>> We are looking forward to that. *However*, there is a lot to be
>> said for regularly re-installing your hosts from scratch. This
>> ensures your installer scripts don't rot as host system "features"
>> accrete over time. This is prone to happen when you Ansible- or
>
> Or as I like to put it: Reboot* often, to ensure that you can. Uptime is
> overrated.
In my experience, there are indeed benefits to rebooting production
servers on a scheduled maintenance basis. Here are two example problems
that it could help with:
1. If long-running processes are running then there is some chance that
the system is suffering memory fragmentation. This will make your
server slower. I think it could also/either trigger an OOM.
2. Untested changes could have been deployed since last reboot. They
might have unpredictable effects on the startup scripts.
3. The startup scripts might no longer work _at all_ if the server has
been in continual operation for a long time, such as five years. This
can happen due to the phenomenon known as "bit rot".
Some benefits of a regular, scheduled reboot cycle:
1. Rebooting will clear up memory fragmentation.
2. Rebooting will improve confidence that it is possible to reboot the
server in a clean way and that the startup scripts still work. After
initial boot the server will progress to its intended runtime state.
("Have you tried turning it off and then back on again?")
Having this kind of confidence is particularly important when a
server crashes or when you need to perform unscheduled maintenance to
deploy to urgent hotfix.
Another thought literally just occurred to me. Regular
_unscheduled_ reboots seem like a typical chaos engineering technique.
I haven't investigated chaos engineering closely but I'd be surprised if
it isn't.
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Ansible install Re: Reboot and re-link
On 22/06/2019 19:52, cho...@jtan.com wrote:
> Lyndon Nerenberg writes:
>> We are looking forward to that. *However*, there is a lot to be
>> said for regularly re-installing your hosts from scratch. This
>> ensures your installer scripts don't rot as host system "features"
>> accrete over time. This is prone to happen when you Ansible- or
>
> Or as I like to put it: Reboot* often, to ensure that you can. Uptime is
> overrated.
In my experience, there are indeed benefits to rebooting production
servers on a scheduled maintenance basis.
If long-running processes are running then there is some chance that the
system is suffering memory fragmentation. This will make your server
slower. I think it could also/either trigger an OOM.
Untested changes could have been deployed since last reboot. They might
have unpredictable side-effects on the startup scripts.
Some benefits of a regular, scheduled reboot cycle:d
1. Rebooting will clear up memory fragmentation.
2. Rebooting will improve confidence that it is possible to reboot the
server and in a clean way and improve confidence that the startup
scripts still work. After initial boot it will progress to its intended
runtime state. ("Have you tried turning it off and then back on again?")
This is particularly important in a situation where a server
crashes, needs unscheduled maintenance, or you need to decide whether it
is safe to reboot
(A thought just occurred to me that the following reasons might be a
part of chaos engineering, which I have been meaning to investigate but
haven't found time yet.)
-- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Ansible install Re: Reboot and re-link
Using Ansible to reinstall the operating system is like trying to turn a four door sedan into a monster truck with a hammer. Wrong tool for the job. > On Jun 22, 2019, at 6:46 PM, Frank Beuth wrote: > >> On Sat, Jun 22, 2019 at 03:06:30AM +0100, Andrew Luke Nesbit wrote: >>> On 21/06/2019 19:02, Frank Beuth wrote: >>> I don't want to re-open the hostilities, but installing OpenBSD via >>> Ansible is very relevant to my interests. >> >> I feel exactly the same way and am surprised that Ansible caused >> hostilities. Can you send me a link to the thread where this happened >> please? I want to know why, i.e., pros and cons. > > It doesn't look to me like Ansible as such caused any trouble, it was > someone's use of Ansible in an unsupported way (and probably many other > configuration choices), leading to further problems, and then people got > angry. > > For details search the misc@ archives for "Reboot and re-link" (the subject > line), things got spread across multiple threads: > https://marc.info/?l=openbsd-misc=2=1=Reboot+and+re-link=t >
Re: Ansible install Re: Reboot and re-link
On Sat, Jun 22, 2019 at 03:06:30AM +0100, Andrew Luke Nesbit wrote: On 21/06/2019 19:02, Frank Beuth wrote: I don't want to re-open the hostilities, but installing OpenBSD via Ansible is very relevant to my interests. I feel exactly the same way and am surprised that Ansible caused hostilities. Can you send me a link to the thread where this happened please? I want to know why, i.e., pros and cons. It doesn't look to me like Ansible as such caused any trouble, it was someone's use of Ansible in an unsupported way (and probably many other configuration choices), leading to further problems, and then people got angry. For details search the misc@ archives for "Reboot and re-link" (the subject line), things got spread across multiple threads: https://marc.info/?l=openbsd-misc=2=1=Reboot+and+re-link=t
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > That's the interesting thing in my case (at least)... the system *IS* already > extant! And how have you introduced it to your command-and-control system? That is, ultimately, the key. > It has a nice shiny new Ubuntu/Debian/Fedora/centOS install that has just > been > imaged onto it using the hosting provider's default tooling, and SSH is > already > configured. (without blindly saying "yes" to the unexpected-fingerprint > prompt) That is what these tools depend on, but how is such a state of "already configured" achieved before the tool that does the configuration gets involved? This is why these are not the right tool for the job. > Normally in this situation one would just use Ansible to harden the default > Linux install and configure whatever applications are needed. But in this > case > I feel like hardening the Linux install even more, by replacing it with > OpenBSD > :) If you're hardening a system you've already lost. Systems should be hard by default. > Maybe I'm wrong, but it seems like if this problem were well-solved then it > would make easier to use OpenBSD in many more applications and situations. It's not well-solved because nobody tries to solve it. Installing systems in the first instance is assumed to be a manual process and no further thought is applied because you've got your clonable image, right? Actually that's not entirely true but I've yet to find a *portable* solution. > I'd love to see your tool. Oooh sir! > PXE is mostly not available for this case (in > general I am trying to target the most generic possible situation). PXE is only applicable in situations where the network can be guaranteed to be trusted; you're letting your DHCP server give you unverifiable code to execute and if you can't trust the network you can't trust the DHCP response. I wrote stash so that I could deploy my own servers without trust being an issue. It got as far as that and I (temporarily; I'll get back to it) lost interest. Nobody is paying me for this, I'm just bored. The documentation is ... poor. But it works. In my little network there are currently 6 distinct servers, all built using it with zero manual interaction. https://github.com/chohag/stash Enjoy. Happy to answer questions (I need some critical feedback). I plan to make more out of this but for the time being it's little more than a toy. Matthew
Re: Ansible install Re: Reboot and re-link
On Sat, Jun 22, 2019 at 10:29:22PM +0300, cho...@jtan.com wrote: Ansible is not the correct tool for this job; it can only configure and maintain an _extant_ system. None of the recent plethora of configuration management tools have considered the scenario *before* an operating system has been installed. All of them expect the server to exist and for secured communication channels to have been established between it and the master control system before they are operable. That's the interesting thing in my case (at least)... the system *IS* already extant! It has a nice shiny new Ubuntu/Debian/Fedora/centOS install that has just been imaged onto it using the hosting provider's default tooling, and SSH is already configured. (without blindly saying "yes" to the unexpected-fingerprint prompt) Normally in this situation one would just use Ansible to harden the default Linux install and configure whatever applications are needed. But in this case I feel like hardening the Linux install even more, by replacing it with OpenBSD :) Maybe I'm wrong, but it seems like if this problem were well-solved then it would make easier to use OpenBSD in many more applications and situations. FWIW I'm working on-and-off on a tool which specifically automates *that* problem (build a new server/vm/chroot with zero human interaction so Ansible et al. can subsequently and safely take over) but what I've released so far is alpha quality at best. Conveniently if you're only targetting OpenBSD then it's entirely useless because, provided you can use PXE*, the OpenBSD developers have already solved it. Without Ansible. Matthew [*] The autoinstall/siteXX.tgz/etc. solution provided by the OpenBSD developers is very good but there are some questions I have around integrity on a potentially untrusted network. However as I'm trying to target more than just OpenBSD, and I don't trust any network, I've simply abandoned the idea of using PXE in my own environments so I haven't looked into the answers to them. YMMV. I'd love to see your tool. PXE is mostly not available for this case (in general I am trying to target the most generic possible situation).
Re: Ansible install Re: Reboot and re-link
On 21/06/2019 19:02, Frank Beuth wrote: > I don't want to re-open the hostilities, but installing OpenBSD via > Ansible is very relevant to my interests. I feel exactly the same way and am surprised that Ansible caused hostilities. Can you send me a link to the thread where this happened please? I want to know why, i.e., pros and cons. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > Yes, and being able to Ansible-manage even the re-installation would make the > whole process that much nicer :) Ansible is not the correct tool for this job; it can only configure and maintain an _extant_ system. None of the recent plethora of configuration management tools have considered the scenario *before* an operating system has been installed. All of them expect the server to exist and for secured communication channels to have been established between it and the master control system before they are operable. The vast majory seem to solve this problem with the moral equivalent of blindly saying "yes" to ssh's unexpected-fingerprint prompt. If you wish to head down that rabbit-hole then best of luck to you. FWIW I'm working on-and-off on a tool which specifically automates *that* problem (build a new server/vm/chroot with zero human interaction so Ansible et al. can subsequently and safely take over) but what I've released so far is alpha quality at best. Conveniently if you're only targetting OpenBSD then it's entirely useless because, provided you can use PXE*, the OpenBSD developers have already solved it. Without Ansible. Matthew [*] The autoinstall/siteXX.tgz/etc. solution provided by the OpenBSD developers is very good but there are some questions I have around integrity on a potentially untrusted network. However as I'm trying to target more than just OpenBSD, and I don't trust any network, I've simply abandoned the idea of using PXE in my own environments so I haven't looked into the answers to them. YMMV.
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > Yes, and being able to Ansible-manage even the re-installation would make the > whole process that much nicer :) I started writing a rebuttal to this, but it quickly turned into writing our design document for how we handle this internally across he data- centre. That's not something I can share. Suffice to say this is not as simple a process as you might think it is. --lyndon
Re: Ansible install Re: Reboot and re-link
Lyndon Nerenberg writes: > We are looking forward to that. *However*, there is a lot to be > said for regularly re-installing your hosts from scratch. This > ensures your installer scripts don't rot as host system "features" > accrete over time. This is prone to happen when you Ansible- or Or as I like to put it: Reboot* often, to ensure that you can. Uptime is overrated. Matthew [*] Or, as in this case, reinstall. It's more or less the same if you're set up right.
Re: Ansible install Re: Reboot and re-link
On Sat, Jun 22, 2019 at 10:28:53AM -0700, Lyndon Nerenberg wrote: We are looking forward to that. *However*, there is a lot to be said for regularly re-installing your hosts from scratch. This ensures your installer scripts don't rot as host system "features" accrete over time. This is prone to happen when you Ansible- or Puppet-manage servers. Things get added, things get removed. Often you miss hidden dependencies that sneak in; you don't want to be discovering those when you're trying to reinstall a production host after a catastrophic failure. Yes, and being able to Ansible-manage even the re-installation would make the whole process that much nicer :)
Re: Correct pexp variable for a shell script
On 6/22/19 12:43 PM, Antoine Jacoutot wrote: > On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: >> On 6/22/19 7:05 AM, Antoine Jacoutot wrote: >>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: I've got a shell script I'd like to run as a system service. Due to the 16 character limitation on pgrep and the -x flag that rc.subr passes to check by default, I can't get check or stop to work correctly. The problem is that the process name looks like "/bin/sh /usr/local/bin/script.sh" which, even if passed to pgrep, won't match when -x is used. My rc.d script currently looks like this: >>> Hi. >>> >>> That should not be an issue, that's why pexp is used for. >>> But without more context it's hard to know how to help you. >>> >>> I can match sh scripts without issue: >>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" >>> 77289 >>> >>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? >>> We don't run into the 16 chars limitation when using -xf >> >> Here's what I was seeing that led me to that conclusion: >> >> rukey$ ps aux | grep authmail >> root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 >> /bin/sh /usr/local/bin/authmail >> jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep >> authmail >> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail >> 51889 >> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail >> >> >> However, I didn't think to quote it. that seems to fix it: >> >> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" >> 51889 >> >> It appears that rc.subr uses quotes, but: >> >> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" >> 51889 >> rukey# rcctl check authmail >> authmail(failed) >> rukey# >> >> Any idea what could be going wrong here? > Dunno, run rcctl in debug mode. rukey# ps ux | grep authmail root 93772 0.0 0.2 272 892 p0 S+p 2:10PM 0:00.01 grep authmail rukey# rcctl -d start authmail doing _rc_parse_conf doing _rc_quirks authmail_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/authmail doing _rc_quirks doing rc_check authmail doing rc_start doing _rc_wait start doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check Alarm clock /etc/rc.d/authmail: kill: 73440: No such process doing _rc_write_runfile (ok) rukey# rcctl -d check authmail doing _rc_parse_conf doing _rc_quirks authmail_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/authmail doing _rc_quirks authmail doing rc_check (failed) rukey# ps | grep authmail 17035 p0 Ip 0:00.01 /bin/sh /usr/local/bin/authmail 25162 p0 R+p 0:00.01 grep authmail rukey#
Re: Ansible install Re: Reboot and re-link
Daniel Jakots writes: > You can automate installation with autoinstall(8). You can also > automate upgrades with autoinstall(8) This works like a charm. On our load balancers we PXE install with a local rc.firsttime that installs python. After that we do all the system, haproxy, nginx, management via ansible. > and from 6.6 you'll be able to > use sysupgrade(8) as well. We are looking forward to that. *However*, there is a lot to be said for regularly re-installing your hosts from scratch. This ensures your installer scripts don't rot as host system "features" accrete over time. This is prone to happen when you Ansible- or Puppet-manage servers. Things get added, things get removed. Often you miss hidden dependencies that sneak in; you don't want to be discovering those when you're trying to reinstall a production host after a catastrophic failure. --lyndon
Re: HIPPA supported ciphers
Kihaguru Gathura writes: [...] > TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 Non-compliant with HIPAA guidance > TLS_RSA_WITH_CAMELL TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant > with HIPAA guidance > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant with HIPAA guidance > Under what circumstances could these ciphers be not considered for > HIPPA compliance? These aren't known to the HIPAA standard, and it doesn't allow unknown ciphers. Just disable the Camellia ciphers and you'll pass the validation. You'll run into similar issues passing PCI-DSS. We use the following settings to make the various validators happy: ssl_ciphers "HIGH:!DES:!3DES:!CHACHA20:!RC4:!MD5:!aNULL:!EDH:!CAMELLIA"; ssl_prefer_server_ciphers on; --lyndon
Re: Correct pexp variable for a shell script
On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: > > On 6/22/19 7:05 AM, Antoine Jacoutot wrote: > > On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: > >> I've got a shell script I'd like to run as a system service. Due to the > >> 16 character limitation on pgrep and the -x flag that rc.subr passes to > >> check by default, I can't get check or stop to work correctly. The > >> problem is that the process name looks like "/bin/sh > >> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match > >> when -x is used. > >> > >> My rc.d script currently looks like this: > >> > > Hi. > > > > That should not be an issue, that's why pexp is used for. > > But without more context it's hard to know how to help you. > > > > I can match sh scripts without issue: > > $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" > > 77289 > > > > Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? > > We don't run into the 16 chars limitation when using -xf > > > Here's what I was seeing that led me to that conclusion: > > rukey$ ps aux | grep authmail > root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 > /bin/sh /usr/local/bin/authmail > jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep > authmail > rukey$ pgrep -f /bin/sh /usr/local/bin/authmail > 51889 > rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail > > > However, I didn't think to quote it. that seems to fix it: > > rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" > 51889 > > It appears that rc.subr uses quotes, but: > > rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" > 51889 > rukey# rcctl check authmail > authmail(failed) > rukey# > > Any idea what could be going wrong here? Dunno, run rcctl in debug mode. -- Antoine
Re: alc0 watchdog timeout
On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote:
> HI
>
> On 6.5-current:
>
> As I wrote @ 1:46 AM, it seems OK!
>
> But, I experiment some troubles on my connexion:
>
> - unwanted SSH disconnections
>
> - on X, with Firefox, tabs crashed always in same time.
>
> Perhaps, for Firefox, it's a problem with pledge?
>
> I see thoses messages in /var/log/messages - egual on 'dmesg':
>
> Jun 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92
> Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
> Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall 92
>
> (...)
>
> firefox[68021]: pledge "flock", syscall 92
> firefox[22469]: pledge "flock", syscall 92
> firefox[41244]: pledge "flock", syscall 92
>
> ???
This happens sometimes when firefox is calling into some library that
hits these syscalls, and those syscalls are not in the firefox pledge.
In my experience this is often some uncommon code path through X,
usually related to which graphics driver you are using, but it could be
anything. When I have this happen to me, it is always on specific
websites that trigger some rendering codepath through X that uses some
unusual way to allocate memory or something. In your case, it could also
be some extension you have loaded.
You can pretty easily see what is going wrong:
When a firefox tab crashes you should have a firefox.core file lying
around (usually in your $HOME, but it will be wherever you launched
firefox from). Run gdb on /usr/local/bin/firefox, and then load up the
core file. It will drop you into the spot where firefox was killed, and
you can check the backtrace to see what code path took you to the system
call that hasn't been pledged.
In this instance, firefox is calling fcntl, which is covered by the
"flock" pledge. You can add "flock" to the
security.sandbox.pledge.content line in about:config and see if that
makes it work for you. If you have at all modified the firefox content
or main pledges from their defaults, you should check to see if
reverting to their defaults helps ("flock" is in the main pledge by
default, but not in the content pledge).
Hope this helps.
Re: Correct pexp variable for a shell script
On 6/22/19 7:05 AM, Antoine Jacoutot wrote: > On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: >> I've got a shell script I'd like to run as a system service. Due to the >> 16 character limitation on pgrep and the -x flag that rc.subr passes to >> check by default, I can't get check or stop to work correctly. The >> problem is that the process name looks like "/bin/sh >> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match >> when -x is used. >> >> My rc.d script currently looks like this: >> > Hi. > > That should not be an issue, that's why pexp is used for. > But without more context it's hard to know how to help you. > > I can match sh scripts without issue: > $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" > 77289 > > Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? > We don't run into the 16 chars limitation when using -xf Here's what I was seeing that led me to that conclusion: rukey$ ps aux | grep authmail root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 /bin/sh /usr/local/bin/authmail jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep authmail rukey$ pgrep -f /bin/sh /usr/local/bin/authmail 51889 rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail However, I didn't think to quote it. that seems to fix it: rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" 51889 It appears that rc.subr uses quotes, but: rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" 51889 rukey# rcctl check authmail authmail(failed) rukey# Any idea what could be going wrong here? Thanks, Jacob
Re: Correct pexp variable for a shell script
On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote:
> I've got a shell script I'd like to run as a system service. Due to the
> 16 character limitation on pgrep and the -x flag that rc.subr passes to
> check by default, I can't get check or stop to work correctly. The
> problem is that the process name looks like "/bin/sh
> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match
> when -x is used.
>
> My rc.d script currently looks like this:
>
Hi.
That should not be an issue, that's why pexp is used for.
But without more context it's hard to know how to help you.
I can match sh scripts without issue:
$ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session"
77289
Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"?
We don't run into the 16 chars limitation when using -xf
> #!/bin/ksh
>
> AUTHMAIL="/usr/local/bin/authmail"
> daemon=${AUTHMAIL}
> daemon_timeout=1
>
> . /etc/rc.d/rc.subr
>
> rc_reload=NO
> rc_bg=YES
> pexp="/bin/sh ${AUTHMAIL}"
>
> rc_cmd $1
>
> Do I have any other options, or do I just need to override rc_check to
> remove -x?
>
>
--
Antoine
Re: alc0 watchdog timeout
HI On 6.5-current: As I wrote @ 1:46 AM, it seems OK! But, I experiment some troubles on my connexion: - unwanted SSH disconnections - on X, with Firefox, tabs crashed always in same time. Perhaps, for Firefox, it's a problem with pledge? I see thoses messages in /var/log/messages - egual on 'dmesg': Jun 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92 Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92 Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall 92 (...) firefox[68021]: pledge "flock", syscall 92 firefox[22469]: pledge "flock", syscall 92 firefox[41244]: pledge "flock", syscall 92 ??? On 6/22/19 6:27 AM, Kevin Lo wrote: > On Fri, Jun 21, 2019 at 09:44:12PM +0200, Stephane HUC "PengouinBSD" wrote: >> HI, > Hi, > >> To communicate on Internet, with my laptop - a Dell Alienware 13 - I >> use an external LAN Adapter USB to RJ. This run correcty! >> >> I did not notice / understood that the physical network card was managed >> . >> >> $ grep alc0 dmesg.txt >> >> alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10: >> msi, address 34:e6:d7:1b:7f:14 >> atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 >> >> But, if I configure inet and inet6 on hostname.alc0 file, either dhcp >> or static informations, dmesg filled with "alc0: watchdog timeout" and >> /var/log/messages grow up! >> >> Into /var/log/messages, as: >> Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times >> Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times >> Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times >> Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times >> Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times >> Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times >> Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times >> Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times >> Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times >> >> With 'dhcp', the system reply: "no lease". >> >> Someone can explain-me the reason (simply), please?! >> (and, perhaps, found a solution…) > I think this bug has been fixed in r1.48. Please try -current, thanks. >
Re: How to specify "device" option in vm.conf to always boot PXE
On Fri, Jun 21, 2019 at 02:38:56PM +0200, Joel Carnat wrote: > Hi, > > I need a VM to always boot from the network. > > I could do it using vmctl(8): > # doas vmctl start test -c -B net -b /bsd -n vswitch0 > (...) > PXE boot MAC address fe:e1:bb:d1:c5:d8, interface vio0 > nfs_boot: using interface vio0, with revarp & bootparams > > But I can't find the syntax to be used in vm.conf(5). > Using "boot /bsd" would not use PXE. > Using "boot /pxeboot" would not boot at all. > > Is it possible to set the boot device as net in vm.conf ? It's possible in -current and will be in the next release. See the manual[1] for further reference. [1] https://man.openbsd.org/vm.conf#boot_device
Re: Ansible install Re: Reboot and re-link
On 6/22/19 7:23 AM, Frank Beuth wrote: > I wonder if there is a way to have Ansible build a custom > autoinstall.conf (using templates) and insert it into bsd.rd immediately > prior to uploading. I use elfrdsetroot from upobsd to do something along these lines $ pkg_info upobsd Information for inst:upobsd-1.1 Comment: download, verify and patch bsd.rd image Description: upobsd is a ksh(1) script designed to download, verify and optionally patch bsd.rd image. upobsd will download bsd.rd image using ftp(1) from mirror defined in installurl(5), will verify the downloaded file using signify(1) and local key inside /etc/signify to ensure integrity, and optionally patch the image for adding auto_install.conf or auto_upgrade.conf file to add support of offline autoinstall(8). Maintainer: Sebastien Marie WWW: https://bitbucket.org/semarie/upobsd
Re: Ansible install Re: Reboot and re-link
On Sat, Jun 22, 2019 at 04:41:47AM +0100, Andrew Luke Nesbit wrote: On 21/06/2019 19:02, Frank Beuth wrote: I don't want to re-open the hostilities, but installing OpenBSD via Ansible is very relevant to my interests. I feel exactly the same way and am surprised that Ansible caused hostilities. Can you send me a link to the thread where this happened please? I want to know why, i.e., pros and cons. It's the parent thread of this one (look for subject line "Reboot and re-link"). The issue was not Ansible, just that the original thread poster got very angry with people.
