Reboot and re-link

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Reboot and re-link

Maxim Bourmistrov-5
Hey,

long story short: reboot and re-link is not practical.

Long story:
Time to upgrade 6.4 to 6.5.
If re-link been active in 6.4 (don't remember) - I never noticed it.
Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
steroides (ansible).
All down. Reboot.
and now I get a SLOW sys - why ?! - compiling new kernel:

load averages:  3.25,  1.45,  0.60

53 processes: 1 running, 49 idle, 3 on processor

                     up  0:04
CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
14.7% idle
CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
20.9% idle
CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
 8.3% idle
CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
29.9% idle
Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
51958 _snmpd    64    0  956K 3148K run/0     -         3:25 119.87% snmpd
17683 root      64    0  166M  174M onproc/2  -         3:10 99.41% ld
59133 root       2    0 1404K 4248K sleep/0   select    0:08 16.70% sshd
39714 root      18    0  908K  988K sleep/1   pause     0:05 12.55% ksh
69806 _tor       2    0   29M   41M sleep/3   kqread    0:28  8.15% tor
56629 _pflogd    4    0  744K  576K sleep/3   bpf       0:19  7.57% pflogd
92193 _iscsid    2    0  732K 1256K sleep/3   kqread    0:15  4.64% iscsid
  288 _squid     2    0   17M   14M sleep/0   kqread    0:11  4.00% squid
53448 _lldpd     2    0 2656K 3848K sleep/3   kqread    0:07  3.32% lldpd
42939 _syslogd   2    0 1108K 1692K sleep/3   kqread    0:03  1.66% syslogd
 2842 _bgpd     10    0 1172K 1896K onproc/1  -         0:03  1.46% bgpd


I don't think THIS IS OK.
I'm lucky - secondary (but, if ONLY primary??)


For whatever reason, after rebooting, I got back 6.4 kernel.
(I'd like to here some great explanation here and MORE around the <subject>)

P.S.
I remember old times then you could fork and forget.
OS position it self as "an ASCII, no sh around and simple". Then why the
process to upgrade became a nightmare?! Was not like this BEFORE.

Hit me with stright answers and no "bs wrap-around".

Ye, btw, the "ansible way" been working before.

//mxb
Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Christer Solskogen-3
>
> Hit me with stright answers and no "bs wrap-around".
>
>
Upgrade to a snapshot using bsd.rd, and use sysupgrade from now on.

--
chs
Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Otto Moerbeek
In reply to this post by Maxim Bourmistrov-5
On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:

> Hey,
>
> long story short: reboot and re-link is not practical.
>
> Long story:
> Time to upgrade 6.4 to 6.5.
> If re-link been active in 6.4 (don't remember) - I never noticed it.
> Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
> steroides (ansible).
> All down. Reboot.
> and now I get a SLOW sys - why ?! - compiling new kernel:
>
> load averages:  3.25,  1.45,  0.60
>
> 53 processes: 1 running, 49 idle, 3 on processor
>
>                      up  0:04
> CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
> 14.7% idle
> CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
> 20.9% idle
> CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
>  8.3% idle
> CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
> 29.9% idle
> Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M
>
>   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> 51958 _snmpd    64    0  956K 3148K run/0     -         3:25 119.87% snmpd
> 17683 root      64    0  166M  174M onproc/2  -         3:10 99.41% ld
> 59133 root       2    0 1404K 4248K sleep/0   select    0:08 16.70% sshd
> 39714 root      18    0  908K  988K sleep/1   pause     0:05 12.55% ksh
> 69806 _tor       2    0   29M   41M sleep/3   kqread    0:28  8.15% tor
> 56629 _pflogd    4    0  744K  576K sleep/3   bpf       0:19  7.57% pflogd
> 92193 _iscsid    2    0  732K 1256K sleep/3   kqread    0:15  4.64% iscsid
>   288 _squid     2    0   17M   14M sleep/0   kqread    0:11  4.00% squid
> 53448 _lldpd     2    0 2656K 3848K sleep/3   kqread    0:07  3.32% lldpd
> 42939 _syslogd   2    0 1108K 1692K sleep/3   kqread    0:03  1.66% syslogd
>  2842 _bgpd     10    0 1172K 1896K onproc/1  -         0:03  1.46% bgpd
>
>
> I don't think THIS IS OK.
> I'm lucky - secondary (but, if ONLY primary??)
>
>
> For whatever reason, after rebooting, I got back 6.4 kernel.
> (I'd like to here some great explanation here and MORE around the <subject>)

Why not investigate why your system is slow? To me it looks like at
least snmpd is having a problem. The ld will disappear at some point.

>
> P.S.
> I remember old times then you could fork and forget.
> OS position it self as "an ASCII, no sh around and simple". Then why the
> process to upgrade became a nightmare?! Was not like this BEFORE.

You could start with following the proper upgrade procedure.

What's difficult about booting into bsd.rd and doing an upgrade?

>
> Hit me with stright answers and no "bs wrap-around".
>
> Ye, btw, the "ansible way" been working before.

It might. But how does that tell if this time it worked properly?

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Stuart Henderson
On 2019-06-20, Otto Moerbeek <[hidden email]> wrote:

> On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
>
>> Hey,
>>
>> long story short: reboot and re-link is not practical.
>>
>> Long story:
>> Time to upgrade 6.4 to 6.5.
>> If re-link been active in 6.4 (don't remember) - I never noticed it.
>> Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
>> steroides (ansible).
>> All down. Reboot.
>> and now I get a SLOW sys - why ?! - compiling new kernel:
>>
>> load averages:  3.25,  1.45,  0.60
>>
>> 53 processes: 1 running, 49 idle, 3 on processor
>>
>>                      up  0:04
>> CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
>> 14.7% idle
>> CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
>> 20.9% idle
>> CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
>>  8.3% idle
>> CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
>> 29.9% idle
>> Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M
>>
>>   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
>> 51958 _snmpd    64    0  956K 3148K run/0     -         3:25 119.87% snmpd
>> 17683 root      64    0  166M  174M onproc/2  -         3:10 99.41% ld
>> 59133 root       2    0 1404K 4248K sleep/0   select    0:08 16.70% sshd
>> 39714 root      18    0  908K  988K sleep/1   pause     0:05 12.55% ksh
>> 69806 _tor       2    0   29M   41M sleep/3   kqread    0:28  8.15% tor
>> 56629 _pflogd    4    0  744K  576K sleep/3   bpf       0:19  7.57% pflogd
>> 92193 _iscsid    2    0  732K 1256K sleep/3   kqread    0:15  4.64% iscsid
>>   288 _squid     2    0   17M   14M sleep/0   kqread    0:11  4.00% squid
>> 53448 _lldpd     2    0 2656K 3848K sleep/3   kqread    0:07  3.32% lldpd
>> 42939 _syslogd   2    0 1108K 1692K sleep/3   kqread    0:03  1.66% syslogd
>>  2842 _bgpd     10    0 1172K 1896K onproc/1  -         0:03  1.46% bgpd
>>
>>
>> I don't think THIS IS OK.
>> I'm lucky - secondary (but, if ONLY primary??)
>>
>>
>> For whatever reason, after rebooting, I got back 6.4 kernel.
>> (I'd like to here some great explanation here and MORE around the <subject>)
>
> Why not investigate why your system is slow? To me it looks like at
> least snmpd is having a problem. The ld will disappear at some point.

Depends on what bgpd is being used for, but there's a high chance snmpd is
churning while bgpd adds new routes. If so then try "filter-routes yes" in
snmpd.conf.

But there are certainly some situations where the relinking is very slow
and a major resource drain indeed. On this system there's plenty of RAM
so maybe just slow disks or cpu (but can't really say much as there's
NO DMESG...*sigh*). On systems with <=256MB running the relink in the
background can be quite a problem depending on what daemons are running.

> You could start with following the proper upgrade procedure.
>
> What's difficult about booting into bsd.rd and doing an upgrade?

Again depends on what bgpd is being used for, but prior to sysupgrade
(which isn't relevant to OP yet as it's on 6.5), getting network in bsd.rd
in order to do a standard upgrade can be quite a challenge.


Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Maxim Bourmistrov-5
What is seen in 'top' is what compile does to the sys. snmpd just freacks
out, and the rest as well.
This is VMWare. Storage below is VSAN.
bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here. Private
stuff, no massive peering. No peering at all, except mentioned.
Compile sucks out all rss and I don't think this is OK to have this machine
in line, handling traffic.
If I had only one node, with active connections, I'd say I'm offline while
compile is active.

//mxb

On Thu, 20 Jun 2019 at 13:05, Stuart Henderson <[hidden email]> wrote:

> On 2019-06-20, Otto Moerbeek <[hidden email]> wrote:
> > On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
> >
> >> Hey,
> >>
> >> long story short: reboot and re-link is not practical.
> >>
> >> Long story:
> >> Time to upgrade 6.4 to 6.5.
> >> If re-link been active in 6.4 (don't remember) - I never noticed it.
> >> Installing via NOT RECOMMENDED WAY(following upgrade65.html) -
> scripting on
> >> steroides (ansible).
> >> All down. Reboot.
> >> and now I get a SLOW sys - why ?! - compiling new kernel:
> >>
> >> load averages:  3.25,  1.45,  0.60
> >>
> >> 53 processes: 1 running, 49 idle, 3 on processor
> >>
> >>                      up  0:04
> >> CPU0 states:  0.0% user,  0.0% nice, 21.0% sys, 63.7% spin,  0.6% intr,
> >> 14.7% idle
> >> CPU1 states:  0.5% user,  0.0% nice, 22.3% sys, 56.2% spin,  0.0% intr,
> >> 20.9% idle
> >> CPU2 states:  0.7% user,  0.0% nice, 71.5% sys, 19.6% spin,  0.0% intr,
> >>  8.3% idle
> >> CPU3 states:  0.5% user,  0.0% nice,  6.3% sys, 63.3% spin,  0.0% intr,
> >> 29.9% idle
> >> Memory: Real: 382M/792M act/tot Free: 1177M Cache: 310M Swap: 0K/1279M
> >>
> >>   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU
> COMMAND
> >> 51958 _snmpd    64    0  956K 3148K run/0     -         3:25 119.87%
> snmpd
> >> 17683 root      64    0  166M  174M onproc/2  -         3:10 99.41% ld
> >> 59133 root       2    0 1404K 4248K sleep/0   select    0:08 16.70% sshd
> >> 39714 root      18    0  908K  988K sleep/1   pause     0:05 12.55% ksh
> >> 69806 _tor       2    0   29M   41M sleep/3   kqread    0:28  8.15% tor
> >> 56629 _pflogd    4    0  744K  576K sleep/3   bpf       0:19  7.57%
> pflogd
> >> 92193 _iscsid    2    0  732K 1256K sleep/3   kqread    0:15  4.64%
> iscsid
> >>   288 _squid     2    0   17M   14M sleep/0   kqread    0:11  4.00%
> squid
> >> 53448 _lldpd     2    0 2656K 3848K sleep/3   kqread    0:07  3.32%
> lldpd
> >> 42939 _syslogd   2    0 1108K 1692K sleep/3   kqread    0:03  1.66%
> syslogd
> >>  2842 _bgpd     10    0 1172K 1896K onproc/1  -         0:03  1.46% bgpd
> >>
> >>
> >> I don't think THIS IS OK.
> >> I'm lucky - secondary (but, if ONLY primary??)
> >>
> >>
> >> For whatever reason, after rebooting, I got back 6.4 kernel.
> >> (I'd like to here some great explanation here and MORE around the
> <subject>)
> >
> > Why not investigate why your system is slow? To me it looks like at
> > least snmpd is having a problem. The ld will disappear at some point.
>
> Depends on what bgpd is being used for, but there's a high chance snmpd is
> churning while bgpd adds new routes. If so then try "filter-routes yes" in
> snmpd.conf.
>
> But there are certainly some situations where the relinking is very slow
> and a major resource drain indeed. On this system there's plenty of RAM
> so maybe just slow disks or cpu (but can't really say much as there's
> NO DMESG...*sigh*). On systems with <=256MB running the relink in the
> background can be quite a problem depending on what daemons are running.
>
> > You could start with following the proper upgrade procedure.
> >
> > What's difficult about booting into bsd.rd and doing an upgrade?
>
> Again depends on what bgpd is being used for, but prior to sysupgrade
> (which isn't relevant to OP yet as it's on 6.5), getting network in bsd.rd
> in order to do a standard upgrade can be quite a challenge.
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Theo de Raadt-2
Maxim Bourmistrov <[hidden email]> wrote:

> What is seen in 'top' is what compile does to the sys. snmpd just freacks
> out, and the rest as well.
> This is VMWare. Storage below is VSAN.
> bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here. Private
> stuff, no massive peering. No peering at all, except mentioned.
> Compile sucks out all rss and I don't think this is OK to have this machine
> in line, handling traffic.
> If I had only one node, with active connections, I'd say I'm offline while
> compile is active.

My laptop does the required relink in under 10 seconds.

    0m05.54s real     0m03.21s user     0m02.15s system

My landisk with 64MB of ram and a 266MHz cpu is a little slow.

It's great you have an opinion.  I have a different opinion.
Isn't it great we can all have different opinions?

Must say, I'm glad I'm not relying on your failing services......

Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Theo de Raadt-2
Theo de Raadt <[hidden email]> wrote:

> Maxim Bourmistrov <[hidden email]> wrote:
>
> > What is seen in 'top' is what compile does to the sys. snmpd just freacks
> > out, and the rest as well.
> > This is VMWare. Storage below is VSAN.
> > bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here. Private
> > stuff, no massive peering. No peering at all, except mentioned.
> > Compile sucks out all rss and I don't think this is OK to have this machine
> > in line, handling traffic.
> > If I had only one node, with active connections, I'd say I'm offline while
> > compile is active.
>
> My laptop does the required relink in under 10 seconds.
>
>     0m05.54s real     0m03.21s user     0m02.15s system
>
> My landisk with 64MB of ram and a 266MHz cpu is a little slow.

BTW the landisk takes 5 minutes.

I normally reboot it with a new kernel, and start a new make build
immediately while it is still relinking a future kernel, which it will
never use, but what do I care.  It's just R&D, it is not production, and
it isn't serious, except when it eventually finds a bug that other
architectures didn't find.

Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Maxim Bourmistrov-5
In reply to this post by Theo de Raadt-2
Why the f I have old kernel?
The ONE taking care of all sh.

On Thu, 20 Jun 2019 at 22:43, Maxim Bourmistrov <[hidden email]>
wrote:

> btw, after reboot, sys converted to 6.4 kernel. yet again
> I removed all /bsd*
> Do I need to rm /usr/obj* as well????
>
> On Thu, 20 Jun 2019 at 22:12, Theo de Raadt <[hidden email]> wrote:
>
>> Maxim Bourmistrov <[hidden email]> wrote:
>>
>> > What is seen in 'top' is what compile does to the sys. snmpd just
>> freacks
>> > out, and the rest as well.
>> > This is VMWare. Storage below is VSAN.
>> > bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here.
>> Private
>> > stuff, no massive peering. No peering at all, except mentioned.
>> > Compile sucks out all rss and I don't think this is OK to have this
>> machine
>> > in line, handling traffic.
>> > If I had only one node, with active connections, I'd say I'm offline
>> while
>> > compile is active.
>>
>> My laptop does the required relink in under 10 seconds.
>>
>>     0m05.54s real     0m03.21s user     0m02.15s system
>>
>> My landisk with 64MB of ram and a 266MHz cpu is a little slow.
>>
>> It's great you have an opinion.  I have a different opinion.
>> Isn't it great we can all have different opinions?
>>
>> Must say, I'm glad I'm not relying on your failing services......
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Stuart Henderson
In reply to this post by Maxim Bourmistrov-5
On 2019-06-20, Maxim Bourmistrov <[hidden email]> wrote:
> What is seen in 'top' is what compile does to the sys. snmpd just freacks
> out, and the rest as well.
> This is VMWare. Storage below is VSAN.
> bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here. Private
> stuff, no massive peering. No peering at all, except mentioned.

ok. (fwiw for whatever reason I don't see very good disk io performance
in OpenBSD under VMware so that probably isn't helping matters here).

> Compile sucks out all rss

That doesn't match the top output you showed. Relinking (not recompiling,
there is no automatic recompiling) is running but you have over a gig free
ram. But the kernel is spinning massively (lock contention?). Maybe you'll
find it works better if you reduce the number of cpus.

>                           and I don't think this is OK to have this machine
> in line, handling traffic.

So don't then, run services on carp addresses, set carpdemote in
hostname.if, and at the end of rc.local background something that waits
for reorder_kernel to finish before promoting again. Or move reorder_kernel
up in /etc/rc (above starting pkg daemons, perhaps) and don't background it.
Or disable relinking and run it manually when you run sysupgrade and
it finds a kernel patch. There are lots of options of things you can try.


Reply | Threaded
Open this post in threaded view
|

Re: Reboot and re-link

Andrew Luke Nesbit-2
In reply to this post by Maxim Bourmistrov-5
Dear Maxim,

How are you?

Have you considered taking time away from the computer and doing
something else for a while?  Abusing people generally doesn't work well
when you're asking for something to be done, regardless of whether or
not it's paid work.

Why would anybody with any self-respect respond to your demands?  For
example, if you were my manager at work I would have reported you to HR
by now.

You seem frustrated.  Are you under a lot of pressure or is it something
else?  These are rhetorical questions.

Have you considered searching deep inside yourself to find a way to
transform this angry energy into something else?

Obviously I don't really want to get involved in your personal life
because it's none of my business.  But whatever you do, please look
after yourself.

Kind regards,

Andrew


On 20/06/2019 22:31, Maxim Bourmistrov wrote:

> Why the f I have old kernel?
> The ONE taking care of all sh.
>
> On Thu, 20 Jun 2019 at 22:43, Maxim Bourmistrov <[hidden email]>
> wrote:
>
>> btw, after reboot, sys converted to 6.4 kernel. yet again
>> I removed all /bsd*
>> Do I need to rm /usr/obj* as well????
>>
>> On Thu, 20 Jun 2019 at 22:12, Theo de Raadt <[hidden email]> wrote:
>>
>>> Maxim Bourmistrov <[hidden email]> wrote:
>>>
>>>> What is seen in 'top' is what compile does to the sys. snmpd just
>>> freacks
>>>> out, and the rest as well.
>>>> This is VMWare. Storage below is VSAN.
>>>> bgpd streches 4 arms - to fw1 and 3 remote VPS. No big deal here.
>>> Private
>>>> stuff, no massive peering. No peering at all, except mentioned.
>>>> Compile sucks out all rss and I don't think this is OK to have this
>>> machine
>>>> in line, handling traffic.
>>>> If I had only one node, with active connections, I'd say I'm offline
>>> while
>>>> compile is active.
>>>
>>> My laptop does the required relink in under 10 seconds.
>>>
>>>     0m05.54s real     0m03.21s user     0m02.15s system
>>>
>>> My landisk with 64MB of ram and a 266MHz cpu is a little slow.
>>>
>>> It's great you have an opinion.  I have a different opinion.
>>> Isn't it great we can all have different opinions?
>>>
>>> Must say, I'm glad I'm not relying on your failing services......
>>>
>>

--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Reply | Threaded
Open this post in threaded view
|

Ansible install Re: Reboot and re-link

Frank Beuth
In reply to this post by Maxim Bourmistrov-5
On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
>Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on
>steroides (ansible).

I don't want to re-open the hostilities, but installing OpenBSD via Ansible is
very relevant to my interests. Previously discussed on this list was a very
roundabout approach using Qemu -- is there a better way now?

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Daniel Jakots-6
On Fri, 21 Jun 2019 20:02:48 +0200, Frank Beuth <[hidden email]>
wrote:

> On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
> >Installing via NOT RECOMMENDED WAY(following upgrade65.html) -
> >scripting on steroides (ansible).  
>
> I don't want to re-open the hostilities, but installing OpenBSD via
> Ansible is very relevant to my interests. Previously discussed on
> this list was a very roundabout approach using Qemu -- is there a
> better way now?
>

You can automate installation with autoinstall(8). You can also
automate upgrades with autoinstall(8) and from 6.6 you'll be able to
use sysupgrade(8) as well.

Cheers,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

OpenBSD lists
In reply to this post by Frank Beuth
On 6/21/2019 11:02 AM, Frank Beuth wrote:

> On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote:
>> Installing via NOT RECOMMENDED WAY(following upgrade65.html) -
>> scripting on
>> steroides (ansible).
>
> I don't want to re-open the hostilities, but installing OpenBSD via
> Ansible is very relevant to my interests. Previously discussed on this
> list was a very roundabout approach using Qemu -- is there a better way
> now?
>

I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my
installs.  I also have an rc.firsttime to download and install the
required packages.

I have my machines configured to use the harddisk first and PXE second.
When I go to upgrade systems, I clear the system's boot block so the
boot process skips to PXE booting.

Once I got the wrinkles ironed out, installs and upgrades are very much
fire-and-forget.  Hell, new server installs just require plugging the
machine into power and network, and then walk away (The BIOS comes
pre-configured with "On power restore: 'Power-on'").

Best part, this solution requires zero third party binaries or tools.

Just yesterday I had to replace a failed webserver.  Replaced the failed
system's MAC in dhcpd.conf and then had the datacenter folks rip the old
system out, install the new one, make sure it powers up, then walk away.
Four hours later, I had a fully operational server up and slinging html,
probably finished a lot sooner, but I didn't bother to check until then.

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Frank Beuth
On Fri, Jun 21, 2019 at 12:36:22PM -0700, Misc User wrote:
>I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my
>installs.  I also have an rc.firsttime to download and install the
>required packages.

Thanks, but neither this nor the autoinstall suggestion seem applicable for my
use case.

I am dealing with virtualized servers which usually start out as
Ubuntu/Debian/Fedora images, then the hosting provider supplies the IP address
and root password for a first-time SSH login.

In many cases it is not possible to upload an ISO to be used as server
installation media, and VNC consoles (if available) are often not even
encrypted. (How would you feel about installing OpenBSD and then having your
root password sent in plaintext at the very beginning?)

I realize installing OpenBSD under these constraints is rather like installing
a ship in a bottle, but it seemed worth it to ask...

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

OpenBSD lists
On 6/21/2019 1:08 PM, Frank Beuth wrote:

> On Fri, Jun 21, 2019 at 12:36:22PM -0700, Misc User wrote:
>> I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my
>> installs.  I also have an rc.firsttime to download and install the
>> required packages.
>
> Thanks, but neither this nor the autoinstall suggestion seem applicable
> for my use case.
>
> I am dealing with virtualized servers which usually start out as
> Ubuntu/Debian/Fedora images, then the hosting provider supplies the IP
> address and root password for a first-time SSH login.
> In many cases it is not possible to upload an ISO to be used as server
> installation media, and VNC consoles (if available) are often not even
> encrypted. (How would you feel about installing OpenBSD and then having
> your root password sent in plaintext at the very beginning?)
>
> I realize installing OpenBSD under these constraints is rather like
> installing a ship in a bottle, but it seemed worth it to ask...

You could stick bsd.rd onto a bootable partition then point grub to it.
You could also disable password login for root and just use a key pair.
That way you wouldn't be sending the password encrypted (or at most only
giving it a password that is useless without console access, then run
'doas passwd' the first chance you get to eliminate even that vector).
That temp password could even be a long string of random junk so long as
you enter it twice.

You could copy bsd.rd and a copy of your pub key into /boot, or carve
out a new partition using some unused disk space.


Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Frank Beuth
On Fri, Jun 21, 2019 at 01:20:44PM -0700, Misc User wrote:

>
>You could stick bsd.rd onto a bootable partition then point grub to it.
>You could also disable password login for root and just use a key pair.
>That way you wouldn't be sending the password encrypted (or at most only
>giving it a password that is useless without console access, then run
>'doas passwd' the first chance you get to eliminate even that vector).
>That temp password could even be a long string of random junk so long as
>you enter it twice.
>
>You could copy bsd.rd and a copy of your pub key into /boot, or carve
>out a new partition using some unused disk space.
>

Yes, the goal is a fully automated and unattended (but "stock," supported, and
rage-free) install.

The process of spinning up a new machine should be "add the IP address to the
Ansible hosts file, run the playbook" as opposed to "dig out VNC and mess about
with everything and get interrupted by someone with something urgent and come
back and try to remember where I was..."

This seems pretty close to doable:

Ansible ought to be capable of dropping the bsd.rd into /boot and adding the
relevant lines to grub, then triggering a restart.

Creating partitions seems unnecessary if we can just get the sets via HTTP,
yes? Resizing partitions post-install would add complexity.

The autoinstall(8) man page (https://man.openbsd.org/autoinstall ) is a little
unclear on whether we need to build a custom dhcpd.conf if we are using a local
auto_install.conf, however I assume the answer is "no".

(If "yes," then Ansible would need to get the MAC address from the server
initially, build the dhcpd.conf, and put it in the bsd.rd before uploading...)

Since parameters such as root password, user's username, user password, user
SSH key, etc should be configured in the Ansible playbook or ancillary files, 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.

For that matter I can't find any instructions for editing bsd.rd or adding
files to it, did I miss a manpage somewhere?

(It's too bad supplying the file locally requires editing the image, it would
be nicer to drop the file onto /boot and then pass the filename as an argument
when booting...)

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Andrew Luke Nesbit-2
In reply to this post by Frank Beuth
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

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Frank Beuth
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.

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

tom ryan
In reply to this post by Frank Beuth
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 <[hidden email]>

WWW: https://bitbucket.org/semarie/upobsd

Reply | Threaded
Open this post in threaded view
|

Re: Ansible install Re: Reboot and re-link

Lyndon Nerenberg (VE6BBM/VE7TFX)
In reply to this post by Daniel Jakots-6
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, &c 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

12