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?
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
On 21 June 2019 14:04:50 BST, Florian Obser wrote: >On Thu, Jun 20, 2019 at 10:47:49PM +0200, mathijs wrote: >> this makes misc@ so much more amusing > >It really doesn't. We are not here to have manure tossed at us for the >audience's amusement. Agreed. This kind of abuse happens in any FOSS project. This "Maxim" is an absolute creep, but many people are far, far worse, even. I wasted so much time and energy in the FOSS project I ran having to take countermeasures against such people.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
On Thu, Jun 20, 2019 at 10:47:49PM +0200, mathijs wrote: > this makes misc@ so much more amusing It really doesn't. We are not here to have manure tossed at us for the audience's amusement. Everytime something like this happens it takes time away from hacking on OpenBSD. It doesn't matter that it wasn't directed at me. I'm part of the project and I care about my fellow developers. -- I'm not entirely sure you are real.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
mathijs writes: > this makes misc@ so much more amusing I didn't join for the soap opera. Matthew
Re: Reboot and re-link
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 > 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 wrote: >> >>> Maxim Bourmistrov 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
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
It was either a really bad joke or mental. Now it is threatening. So sad. Jan On 20 Jun 2019, at 23:54, Theo de Raadt wrote: Someone is going to have regrets. Maxim Bourmistrov wrote: IF NOT, I'll start to talk to Canadian govs On Thu, 20 Jun 2019 at 23:48, Maxim Bourmistrov wrote: Now, I'd like to se all bills.As I'm funding this project. 5 years from now on. On Thu, 20 Jun 2019 at 23:25, Maxim Bourmistrov wrote: I'd say this whole project is your milking cow.(Having a good times biking??) You really don't move froward much. Except poor guy trying to fix net stack. You move around vars, back and forward. But really - no progress. Community thinks their push money to dev stuff, in real - their push Theos bills forward. Nice illusion. I'm yet another one in this line. Disappointed, seen to much AND been rejected by Theos. One in line. On Thu, 20 Jun 2019 at 23:08, Maxim Bourmistrov wrote: For me, this does not really matter. ) I give a sh. You just loose yet another testbed. On Thu, 20 Jun 2019 at 23:05, Maxim Bourmistrov wrote: The OpenBSD user community is has too many people like this. I think ppl get frustrated. Like me, been following obsd since 3.2. I think look down on those whom uses your fork. and yet, you want donations. I think that you have to ask first, if you want to get public private conversation. I think this is controlled by law. On Thu, 20 Jun 2019 at 22:51, Theo de Raadt wrote: The OpenBSD user community is has too many people like this. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:34:54 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:35:21 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Fix it NOW! On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov wrote: Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:41:25 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt You are not true here. You get paid. Fuck man, I like OS and been following for a long time. Team does good stuff. But something is not OK, since 6.5. Question is what is not OK. You devs might help out.
Re: Reboot and re-link
On 2019-06-20, Maxim Bourmistrov 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.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
On 6/20/19 5:31 PM, Theo de Raadt wrote: It just doesn't stop. Maxim Bourmistrov wrote: I'd say this whole project is your milking cow.(Having a good times biking??) You really don't move froward much. Except poor guy trying to fix net stack. You move around vars, back and forward. But really - no progress. Community thinks their push money to dev stuff, in real - their push Theos bills forward. Nice illusion. I'm yet another one in this line. Disappointed, seen to much AND been rejected by Theos. One in line. This is why kill files were invented.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
Someone is going to have regrets. Maxim Bourmistrov wrote: > IF NOT, I'll start to talk to Canadian govs > > On Thu, 20 Jun 2019 at 23:48, Maxim Bourmistrov > wrote: > > Now, I'd like to se all bills.As I'm funding this project. 5 years from now > on. > > On Thu, 20 Jun 2019 at 23:25, Maxim Bourmistrov > wrote: > > I'd say this whole project is your milking cow.(Having a good times biking??) > You really don't move froward much. Except poor guy trying to fix net stack. > You move around vars, back and forward. But really - no progress. > Community thinks their push money to dev stuff, in real - their push Theos > bills forward. Nice illusion. > I'm yet another one in this line. Disappointed, seen to much AND been > rejected > by Theos. One in line. > > On Thu, 20 Jun 2019 at 23:08, Maxim Bourmistrov > wrote: > > For me, this does not really matter. ) > I give a sh. > You just loose yet another testbed. > > On Thu, 20 Jun 2019 at 23:05, Maxim Bourmistrov > wrote: > > > The OpenBSD user community is has too many people like this. > I think ppl get frustrated. Like me, been following obsd since 3.2. > I think look down on those whom uses your fork. > and yet, you want donations. > I think that you have to ask first, if you want to get public private > conversation. > I think this is controlled by law. > > > On Thu, 20 Jun 2019 at 22:51, Theo de Raadt > wrote: > > The OpenBSD user community is has too many people like this. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:34:54 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt > wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:35:21 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Fix it NOW! > > On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov > wrote: > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt > wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:41:25 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > You are not true here. > You get paid. > Fuck man, I like OS and been following for a long time. Team does > good stuff. > But something is not OK, since 6.5. > Question is what is not OK. > You devs might help out. >
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
this makes misc@ so much more amusing On 6/20/19 10:44 PM, Theo de Raadt wrote: The OpenBSD user community is has too many people like this. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:34:54 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:35:21 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Fix it NOW! On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov wrote: Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:41:25 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt You are not true here. You get paid. Fuck man, I like OS and been following for a long time. Team does good stuff. But something is not OK, since 6.5. Question is what is not OK. You devs might help out.
Re: Reboot and re-link
Why the f I have old kernel? The ONE taking care of all sh. On Thu, 20 Jun 2019 at 22:43, Maxim Bourmistrov 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 wrote: > >> Maxim Bourmistrov 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.. >> >
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
It just doesn't stop. Maxim Bourmistrov wrote: > I'd say this whole project is your milking cow.(Having a good times biking??) > You really don't move froward much. Except poor guy trying to fix net stack. > You move around vars, back and forward. But really - no progress. > Community thinks their push money to dev stuff, in real - their push Theos > bills > forward. Nice illusion. > I'm yet another one in this line. Disappointed, seen to much AND been > rejected by > Theos. One in line. > > On Thu, 20 Jun 2019 at 23:08, Maxim Bourmistrov > wrote: > > For me, this does not really matter. ) > I give a sh. > You just loose yet another testbed. > > On Thu, 20 Jun 2019 at 23:05, Maxim Bourmistrov > wrote: > > > The OpenBSD user community is has too many people like this. > I think ppl get frustrated. Like me, been following obsd since 3.2. > I think look down on those whom uses your fork. > and yet, you want donations. > I think that you have to ask first, if you want to get public private > conversation. > I think this is controlled by law. > > > On Thu, 20 Jun 2019 at 22:51, Theo de Raadt wrote: > > The OpenBSD user community is has too many people like this. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:34:54 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:35:21 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Fix it NOW! > > On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov > wrote: > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:41:25 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > You are not true here. > You get paid. > Fuck man, I like OS and been following for a long time. Team does good > stuff. > But something is not OK, since 6.5. > Question is what is not OK. > You devs might help out. >
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
As just a “user” who has been trying to learn the OpenBSD way (which does take some effort), I’m very thankful to you and all the devs. It’s comedically sad to see the transition from “installing via NOT RECOMMENDED WAY” to “I’m your user - FIX IT.” Sorry you are catching needless abuse, and thank you for doing so. Bryan
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
Theo de Raadt wrote: > I wish he would leave me alone, I don't need his accusations. > > This Maxim obviously works for someone. Sometimes I wonder if I > should make a phone call. I cannot tell for sure, but maybe it is one of these people. https://www.verisure.com/about-us I lead and collaborate with a group of volunteer software developers and then we *give it all away for free without any warrantee* There is absolutely no reason for any toxic abuse towards our group, or me.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
I wish he would leave me alone, I don't need his accusations. This Maxim obviously works for someone. Sometimes I wonder if I should make a phone call. Maxim Bourmistrov wrote: > > The OpenBSD user community is has too many people like this. > I think ppl get frustrated. Like me, been following obsd since 3.2. > I think look down on those whom uses your fork. > and yet, you want donations. > I think that you have to ask first, if you want to get public private > conversation. > I think this is controlled by law. > > > On Thu, 20 Jun 2019 at 22:51, Theo de Raadt wrote: > > The OpenBSD user community is has too many people like this. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:34:54 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:35:21 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > Fix it NOW! > > On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov > wrote: > > Go away?! I'm your user - FIX IT. > > On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > > From: Maxim Bourmistrov > Date: Thu, 20 Jun 2019 22:41:25 +0200 > Subject: Re: Reboot and re-link > To: Theo de Raadt > > You are not true here. > You get paid. > Fuck man, I like OS and been following for a long time. Team does good stuff. > But something is not OK, since 6.5. > Question is what is not OK. > You devs might help out. >
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
Honestly I think the best thing is to ignore people like this. From the start it was clear that this is a very angry person who needs to spend more time looking in the mirror and less time at the computer. I used to run a FLOSS project and experienced this kind of abuse regularly. Andrew On 20 June 2019 21:44:16 BST, Theo de Raadt wrote: >The OpenBSD user community is has too many people like this. > > >From: Maxim Bourmistrov >Date: Thu, 20 Jun 2019 22:34:54 +0200 >Subject: Re: Reboot and re-link >To: Theo de Raadt > >Go away?! I'm your user - FIX IT. > >On Thu, 20 Jun 2019 at 22:32, Theo de Raadt >wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > >From: Maxim Bourmistrov >Date: Thu, 20 Jun 2019 22:35:21 +0200 >Subject: Re: Reboot and re-link >To: Theo de Raadt > >Fix it NOW! > >On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov > wrote: > > Go away?! I'm your user - FIX IT. > >On Thu, 20 Jun 2019 at 22:32, Theo de Raadt >wrote: > > I take a lot of responsibility, which is why the system has KARL. > > Go away. > >From: Maxim Bourmistrov >Date: Thu, 20 Jun 2019 22:41:25 +0200 >Subject: Re: Reboot and re-link >To: Theo de Raadt > >You are not true here. >You get paid. >Fuck man, I like OS and been following for a long time. Team does good >stuff. >But something is not OK, since 6.5. >Question is what is not OK. >You devs might help out.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
The OpenBSD user community is has too many people like this. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:34:54 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:35:21 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt Fix it NOW! On Thu, 20 Jun 2019 at 22:34, Maxim Bourmistrov wrote: Go away?! I'm your user - FIX IT. On Thu, 20 Jun 2019 at 22:32, Theo de Raadt wrote: I take a lot of responsibility, which is why the system has KARL. Go away. From: Maxim Bourmistrov Date: Thu, 20 Jun 2019 22:41:25 +0200 Subject: Re: Reboot and re-link To: Theo de Raadt You are not true here. You get paid. Fuck man, I like OS and been following for a long time. Team does good stuff. But something is not OK, since 6.5. Question is what is not OK. You devs might help out.
Re: Reboot and re-link
Theo de Raadt wrote: > Maxim Bourmistrov 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.
Re: Reboot and re-link
Maxim Bourmistrov 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..
Re: Reboot and re-link
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 wrote: > On 2019-06-20, Otto Moerbeek 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 TIMECPU > COMMAND > >> 51958 _snmpd640 956K 3148K run/0 - 3:25 119.87% > snmpd > >> 17683 root 640 166M 174M onproc/2 - 3:10 99.41% ld > >> 59133 root 20 1404K 4248K sleep/0 select0:08 16.70% sshd > >> 39714 root 180 908K 988K sleep/1 pause 0:05 12.55% ksh > >> 69806 _tor 20 29M 41M sleep/3 kqread0:28 8.15% tor > >> 56629 _pflogd40 744K 576K sleep/3 bpf 0:19 7.57% > pflogd > >> 92193 _iscsid20 732K 1256K sleep/3 kqread0:15 4.64% > iscsid > >> 288 _squid 20 17M 14M sleep/0 kqread0:11 4.00% > squid > >> 53448 _lldpd 20 2656K 3848K sleep/3 kqread0:07 3.32% > lldpd > >> 42939 _syslogd 20 1108K 1692K sleep/3 kqread0:03 1.66% > syslogd > >> 2842 _bgpd 100 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 > ) > > > > 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. > > >
Re: Reboot and re-link
On 2019-06-20, Otto Moerbeek 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 TIMECPU COMMAND >> 51958 _snmpd640 956K 3148K run/0 - 3:25 119.87% snmpd >> 17683 root 640 166M 174M onproc/2 - 3:10 99.41% ld >> 59133 root 20 1404K 4248K sleep/0 select0:08 16.70% sshd >> 39714 root 180 908K 988K sleep/1 pause 0:05 12.55% ksh >> 69806 _tor 20 29M 41M sleep/3 kqread0:28 8.15% tor >> 56629 _pflogd40 744K 576K sleep/3 bpf 0:19 7.57% pflogd >> 92193 _iscsid20 732K 1256K sleep/3 kqread0:15 4.64% iscsid >> 288 _squid 20 17M 14M sleep/0 kqread0:11 4.00% squid >> 53448 _lldpd 20 2656K 3848K sleep/3 kqread0:07 3.32% lldpd >> 42939 _syslogd 20 1108K 1692K sleep/3 kqread0:03 1.66% syslogd >> 2842 _bgpd 100 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 ) > > 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.
Re: Reboot and re-link
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 TIMECPU COMMAND > 51958 _snmpd640 956K 3148K run/0 - 3:25 119.87% snmpd > 17683 root 640 166M 174M onproc/2 - 3:10 99.41% ld > 59133 root 20 1404K 4248K sleep/0 select0:08 16.70% sshd > 39714 root 180 908K 988K sleep/1 pause 0:05 12.55% ksh > 69806 _tor 20 29M 41M sleep/3 kqread0:28 8.15% tor > 56629 _pflogd40 744K 576K sleep/3 bpf 0:19 7.57% pflogd > 92193 _iscsid20 732K 1256K sleep/3 kqread0:15 4.64% iscsid > 288 _squid 20 17M 14M sleep/0 kqread0:11 4.00% squid > 53448 _lldpd 20 2656K 3848K sleep/3 kqread0:07 3.32% lldpd > 42939 _syslogd 20 1108K 1692K sleep/3 kqread0:03 1.66% syslogd > 2842 _bgpd 100 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 ) 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
Re: Reboot and re-link
> > Hit me with stright answers and no "bs wrap-around". > > Upgrade to a snapshot using bsd.rd, and use sysupgrade from now on. -- chs
