Re: bwfm bcm43569
Provide a dmesg before you rant. Thanks, Brian > On Jun 24, 2019, at 5:06 PM, 3 wrote: > > i know that wifi adapters never worked in obsd(excluding those > adapters for which drivers were written by vendors), but i found one > that shows signs of life in 11n(11ac 2t2r supported by chip). it can > be bought anywhere where there are samsung tv. moreover it even works > in hostap mode(unlike the buggy athn). > but without a ton of bugs not done: > bwfm0: could not read register: TIMEOUT > bwfm0: could not open rx pipe: IN_USE > bwfm0: could not init bus > bwfm0: firmware did not start up > ..and sometimes kernel panic on boot, but works would still! > meet https://wikidevi.com/wiki/Samsung_WCH730B > bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 > Wireless Adapter" rev 2.10/0.01 addr 2 > photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg > it is shown where to solder the wires for wifi. on the right through > two pins(ground is first) is bluetooth, but for obsd this does not > matter(thx theo). > data sheet for chip: https://www.cypress.com/file/310246/download >
bwfm bcm43569
i know that wifi adapters never worked in obsd(excluding those adapters for which drivers were written by vendors), but i found one that shows signs of life in 11n(11ac 2t2r supported by chip). it can be bought anywhere where there are samsung tv. moreover it even works in hostap mode(unlike the buggy athn). but without a ton of bugs not done: bwfm0: could not read register: TIMEOUT bwfm0: could not open rx pipe: IN_USE bwfm0: could not init bus bwfm0: firmware did not start up ..and sometimes kernel panic on boot, but works would still! meet https://wikidevi.com/wiki/Samsung_WCH730B bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 Wireless Adapter" rev 2.10/0.01 addr 2 photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg it is shown where to solder the wires for wifi. on the right through two pins(ground is first) is bluetooth, but for obsd this does not matter(thx theo). data sheet for chip: https://www.cypress.com/file/310246/download
Re: ospf point to point network
On 23/06/2019 19:39, Stuart Henderson wrote: On 2019-06-22, Henry Bonath wrote: What about GRE(4) with a Cisco router on the other end? /etc/hostname.gre123: 1.1.1.1 1.1.1.2 netmask 255.255.255.252 up tunnel IP.OF.OB.SD IP.OF.I.OS Cisco IOS: ! interface Tunnel123 ip address 1.1.1.2 255.255.255.252 tunnel source GigabitEthernet0/0/1 tunnel destination IP.OF.OB.SD tunnel mode gre ! That's likely to work, at the expense of reduced MTU. But is it really worth it? The main problem with ethernet interfaces and ospfd was a bug with DR elections but that has been fixed for a while now. Yes, broadcast type network works fine. I was just hoping getting rid of the whole election thing and maybe a faster ospf sum-up. thanks all for all the input, G
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: Route through different gateways depending on process
On Mon, Jun 24, 2019 at 08:47:38AM +, slackwaree wrote: > Hello, > > > Could you maybe provide a full case study for this as it is fairly > uncommon task? > > Do you mean that I will also need +2 ip aliases next to the boxes main ip? No. You can use either option. The question is how are the proxy users talking to those 3 different proxies? If you want to use port 8080 for all of them you want 3 different IPs. > Eg instead of > 192.168.10.1: 3128 3129 3130 > > 192.168.10.1:3128 using gateway 192.168.10.250 > 192.168.10.2:3128 using gateway 192.168.10.251 > 192.168.10.3:3128 using gateway 192.168.10.252 > Try it out yourself. Create an extra table and run a proxy in it. Use tools like tcpdump, nc, etc to check if it works. Start with: route -T1 add default 192.168.10.250 route -T1 exec "squid command to run ideal with debugging on" -- :wq Claudio > ‐‐‐ Original Message ‐‐‐ > On Friday, June 21, 2019 8:27 PM, Brian Brombacher > wrote: > > > You’ll also need PF rules to allow incoming traffic from your squid clients > > to go to the routing table where your squid process is running. > > > > > On Jun 21, 2019, at 10:28 AM, Claudio Jeker cje...@diehard.n-r-g.com > > > wrote: > > > > > > > On Fri, Jun 21, 2019 at 02:11:53PM +, slackwaree wrote: > > > > Hello, > > > > I wonder if the following scenario can be solved with OpenBSD on 1 > > > > single machine or with VMM: > > > > I got 3 OpenBSD vms, all of them are exactly the same running squid > > > > except they use different default routers to route their traffic out. > > > > I would like to merge these to one VM if it is possible somehow to tell > > > > OpenBSD to use different gateway depending on the squid process. > > > > If not would the same thing be possible with VMMs? All the gateways are > > > > in the same IP range. > > > > > > A simple way to solve this is with multiple routing tables. > > > Create multiple routing tables with: > > > route -T1 add default > > > route -T2 add default > > > route -T3 add default > > > And start the 3 squid processes with route -T1 exec, route -T2 exec. > > > You can also use the the *_rtable variable in rc.d(8) to do that > > > automatically. > > > This requires that the 3 squids listen on different IPs or ports. > > > -- > > > :wq Claudio
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: Route through different gateways depending on process
Hello, Could you maybe provide a full case study for this as it is fairly uncommon task? Do you mean that I will also need +2 ip aliases next to the boxes main ip? Eg instead of 192.168.10.1: 3128 3129 3130 192.168.10.1:3128 using gateway 192.168.10.250 192.168.10.2:3128 using gateway 192.168.10.251 192.168.10.3:3128 using gateway 192.168.10.252 ‐‐‐ Original Message ‐‐‐ On Friday, June 21, 2019 8:27 PM, Brian Brombacher wrote: > You’ll also need PF rules to allow incoming traffic from your squid clients > to go to the routing table where your squid process is running. > > > On Jun 21, 2019, at 10:28 AM, Claudio Jeker cje...@diehard.n-r-g.com wrote: > > > > > On Fri, Jun 21, 2019 at 02:11:53PM +, slackwaree wrote: > > > Hello, > > > I wonder if the following scenario can be solved with OpenBSD on 1 single > > > machine or with VMM: > > > I got 3 OpenBSD vms, all of them are exactly the same running squid > > > except they use different default routers to route their traffic out. > > > I would like to merge these to one VM if it is possible somehow to tell > > > OpenBSD to use different gateway depending on the squid process. > > > If not would the same thing be possible with VMMs? All the gateways are > > > in the same IP range. > > > > A simple way to solve this is with multiple routing tables. > > Create multiple routing tables with: > > route -T1 add default > > route -T2 add default > > route -T3 add default > > And start the 3 squid processes with route -T1 exec, route -T2 exec. > > You can also use the the *_rtable variable in rc.d(8) to do that > > automatically. > > This requires that the 3 squids listen on different IPs or ports. > > -- > > :wq Claudio
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.
