Re: Ansible install Re: Reboot and re-link
On Mon, Jun 24, 2019 at 10:59:44AM +0200, David Sastre wrote: I would not consider ansible as the right tool to provision a system from scratch (as in PXE booting, etc...). Ansible is better used on a system you can connect to using SSH and perform actions as required, with or without doas, as you surely know. You don't mention cloud providers/VPS you are trying to bootstrap OpenBSD to, but the way I'd tackle this situation, if I have understood your use case correctly, is as follows: - Find out if the specific cloud provider is supported by packer [1] (packer itself can be run in OpenBSD[2]). Custom builders can be written, but might be overkill for the task at hand. - If the answer is yes, create a template to bootstrap an OpenBSD image. You can find many examples online[3]. The specifics of the packer template vary depending on the cloud provider, but usually you can bootstrap the system from an ISO (or an existing AMI, if in AWS), and finish provisioning the configuration using ansible. And what if the answer is no? You didn't mention that :) Yes, Ansible is not really the right tool for installing new images onto machines or re-imaging server. Yes, Packer and Terraform (both from the same company) are superb and wonderful ways of managing machines on AWS/Azure/the rest of the API-enabled IaaS crowd. However great the Big Cloud providers are, though, sometimes they are not suitable for a project, and instead one is left in the position of bartering a cow in exchange for a VPS instance at HostElbonia, where you're lucky if the API is RFC 2549 compliant. And in general, one of the things I like most about OpenBSD is the design for simplicity, emphasizing standard, boring interfaces that are extremely reliable and which don't require the "hot new shiny object" du jour. So while yes, automated provisioning of AWS over the API is an option, as is setting up the Linux VPS as a hypervisor running OpenBSD... it doesn't quite feel right. It sounds like a custom bsd.rd with auto_install.conf, dropped onto the /boot partition by Ansible (or some other script or management tool!) is the way to go for this. Ihave a few other projects to deal with, but it is on my to-do list, and if I come up with something potentially useful to others then I will try and write it up in some form.
Re: Ansible install Re: Reboot and re-link
On Mon, Jun 24, 2019 at 11:43:36AM +0300, Gregory Edigarov wrote:
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?
it's all easy given it is some IaaS provider, just use terraform to
create the ground, (terraform could also be used to upload keys, and
do some preconfiguration) then call ansible.
Terraform looks great, but while some of the providers I need to support are
listed (https://www.terraform.io/docs/providers/index.html ) that's not true of
all of them, and probably never will be. In general, being bound to Big Cloud
(AWS / DigitalOcean / et al) is not desirable.
On top of this, my objective for this project is to support the most generic
and standardised possible interface ("image with the provider's web interface
and SSH in after") rather than develop a system that implicitly encourages
lock-in.
Nevertheless looks like a superb tool if it fits.
Re: Ansible install Re: Reboot and re-link
On Fri, Jun 21, 2019 at 11:50 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... Apologies for a late reply to this thread. I would not consider ansible as the right tool to provision a system from scratch (as in PXE booting, etc...). Ansible is better used on a system you can connect to using SSH and perform actions as required, with or without doas, as you surely know. You don't mention cloud providers/VPS you are trying to bootstrap OpenBSD to, but the way I'd tackle this situation, if I have understood your use case correctly, is as follows: - Find out if the specific cloud provider is supported by packer [1] (packer itself can be run in OpenBSD[2]). Custom builders can be written, but might be overkill for the task at hand. - If the answer is yes, create a template to bootstrap an OpenBSD image. You can find many examples online[3]. The specifics of the packer template vary depending on the cloud provider, but usually you can bootstrap the system from an ISO (or an existing AMI, if in AWS), and finish provisioning the configuration using ansible. - From that point onwards, use ansible to further modify the settings in the managed system, prevent configuration drift, if your use case includes the eventual manual actions and/or reflect in ansible tasks/playbooks any modifications applied to the system, so as to be able to reproduce them again if required. - One further option if the OS provided by the hosting service has to be a Linux system would be to consider using it as an hypervisor for OpenBSD VMs. Do let me know if this is the type of provisioning you are looking into. Regards. [1] https://packer.io/docs/builders/index.html [2] https://packer.io/downloads.html [3] https://github.com/kaorimatz/packer-templates/blob/master/openbsd-6.3-amd64.json # there are many other examples online, this is just one of them, I haven't tested it
Re: Ansible install Re: Reboot and re-link
On 21.06.19 21:02, 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? it's all easy given it is some IaaS provider, just use terraform to create the ground, (terraform could also be used to upload keys, and do some preconfiguration) then call ansible. my worst timing on AWS is ~20 minutes. baremetal servers are more interesting beasts here but if your colocation/infrastructure provider allows for boot image uploads that's also quite doable with existing tools.
Re: Ansible install Re: Reboot and re-link
On Sun, Jun 23, 2019 at 10:49:22AM +0300, cho...@jtan.com wrote: Frank Beuth writes: You go ahead and continue to trust your VPS without taking any care to consider where your software comes from. It's choices like that which make "hardening" even be a thing. Have you considered _not_ building a system on a foundation made of cheese? Of course, but those are the constraints I have to deal with. Naturally a dedicated bare-metal server would be preferable, but that is not always possible. Given the tremendous popularity of VPS hosting, it does seem like I am not alone. Just because there is risk on the back-end of the system does not mean we should be careless in other respects.
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > You go ahead and continue to trust your VPS without taking any care to consider where your software comes from. It's choices like that which make "hardening" even be a thing. Have you considered _not_ building a system on a foundation made of cheese? Have fun with that. Matthew
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&w=2&r=1&s=Reboot+and+re-link&q=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&w=2&r=1&s=Reboot+and+re-link&q=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: 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, &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
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.
Re: Ansible install Re: Reboot and re-link
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...)
Re: Ansible install Re: Reboot and re-link
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...
Re: Ansible install Re: Reboot and re-link
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.
Re: Ansible install Re: Reboot and re-link
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.
Re: Ansible install Re: Reboot and re-link
On Fri, 21 Jun 2019 20:02:48 +0200, 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? > 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
Ansible install Re: Reboot and re-link
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?
