pip install (python3) requires some development libraries
Hello. I'm trying to install some django components, which require development libraries be installed on the system to successfully compile. If it goes about Ubuntu I understand that I have to install something like "packet-dev" with the command "sudo apt install packet-dev" What are my steps to make something equal on OpenBSD (6.3/amd64)? I suppose I should begin with fetching the ports tree. But what else? How do I make install script find the dev-libraries needed? In my case I'm trying to install django-ldap-auth using pip. When the installer begins to compile he complains that it cannot find some files: "In file included from Modules/LDAPObject.c:8: Modules/constants.h:7:10: fatal error: 'lber.h' file not found #include "lber.h" 1 error generated. error: command 'cc' failed with exit status 1" -- Best regards Maksim Rodin
Re: Let's Encrypt Error with cgit, httpd, acme-client
Your suggestion of changing things up in my /etc/httpd.conf file did the
trick! My initial version of the file, prior to initializing the
account and requesting a new domain key ended up looking like this based
on your suggestions:
ext_ip="0.0.0.0"
#server "localhost" {
server "git.example.com" {
listen on $ext_ip port 80
# serve the cgit static files directly
location "/cgit.*" {
root "/cgit"
no fastcgi
}
location "/.well-known/acme-challenge/*" {
root { "/acme", strip 2 }
}
# cgit CGI
location "*" {
root "/cgi-bin/cgit.cgi"
fastcgi socket "/run/slowcgi.sock"
}
}
After I was able to successfully run
# acme-client -vAD git.example.com
I modified /etc/httpd.conf to:
ext_ip="0.0.0.0"
#server "localhost" {
server "git.example.com" {
#listen on $ext_ip port 80
listen on * tls port 443
tls certificate "/etc/ssl/git.example.com.fullchain.pem"
tls key "/etc/ssl/private/git.example.com.key"
# serve the cgit static files directly
location "/cgit.*" {
root "/cgit"
no fastcgi
}
location "/.well-known/acme-challenge/*" {
root { "/acme", strip 2 }
}
# cgit CGI
location "*" {
root "/cgi-bin/cgit.cgi"
fastcgi socket "/run/slowcgi.sock"
}
}
server "git.example.com" {
listen on * port 80
block return 301 "https://git.example.com$REQUEST_URI";
}
The site now gets an "A" grade over at ssllabs.com.
I guess my only remaining question is how did you know I needed to make
this change? I know the OpenBSD documentation is really good but I'm
still fascinated how people manage to sort things like this out. Maybe
it's just pure experience?
Either way, thanks again!
Samir
This e-mail, and any attachments are strictly confidential and intended for the
addressee(s) only. The content may also contain legal, professional or other
privileged information. If you are not the intended recipient, please notify
the sender immediately and then delete the e-mail and any attachments. You
should not disclose, copy or take any action in reliance on this transmission.
You may report the matter by contacting us via our UK Contacts
Page (accessed by clicking on the
appropriate link)
Please ensure you have adequate virus protection before you open or detach any
documents from this transmission. National Grid plc and its affiliates do not
accept any liability for viruses. An e-mail reply to this address may be
subject to monitoring for operational reasons or lawful business practices.
For the registered information on the UK operating companies within the
National Grid group please use the attached link:
https://www.nationalgrid.com/group/about-us/corporate-registrations
Re: getting scrollback buffer on OpenBSD 6.3
On Aug 26, 2018 3:18 PM, joshua stein wrote: > > On Sun, 26 Aug 2018 at 13:28:24 -0500, ed...@pettijohn-web.com wrote: > > I'm guessing > > > > dmesg | grep drm > > > > Should help since it won't work with inteldrm nor radeondrm. > > Just for the archives, scrollback support for rasops consoles (like > inteldrm and radeondrm) was added after 6.3. > Can't wait for 6.4 then.
Re: Deploy Django app - strategy?
On 26/08/2018 21:01, Paul de Weerd wrote: Use python3 -m venv /path/to/venv to create a virtualenv using python3 and be done with it. Yeah, it did the trick. I'm going to deplrecate use of virtualenv, since it's no longer needed with Python 3.6. That will use a symlink to the actual python3 binary in /usr/local, so no issues with the lack of wxallowed on /var. However, you'll have to deal with the chroot implications there... I guess it's a non-starter with Django... I guess it'd be easier to simply run it in Docker. What webserver are you using? It's pretty standard stack: * postgresql on localhost * uwsgi on localhost with http/fastcgi protocol * httpd on egress Best regards, Chris
Re: getting scrollback buffer on OpenBSD 6.3
On Sun, 26 Aug 2018 at 13:28:24 -0500, ed...@pettijohn-web.com wrote: > I'm guessing > > dmesg | grep drm > > Should help since it won't work with inteldrm nor radeondrm. Just for the archives, scrollback support for rasops consoles (like inteldrm and radeondrm) was added after 6.3.
Re: Deploy Django app - strategy?
Use python3 -m venv /path/to/venv to create a virtualenv using python3 and be done with it. That will use a symlink to the actual python3 binary in /usr/local, so no issues with the lack of wxallowed on /var. However, you'll have to deal with the chroot implications there... What webserver are you using? You could stick things in a separate partition under /var/www that's mounted with wxallowed. Good luck... Paul 'WEiRD' de Weerd On Sun, Aug 26, 2018 at 07:56:14PM +0100, Chris Narkiewicz wrote: | I'm deploying a Django app on OpenBSD 6.3 and I'm strugging to | wrap my head around the best practices here. | | On Linux we just bootstrap virtualenv in home directory and start | uwsgi (or altenative), but on OpenBSD it seems to be a bit more | complicated: | | core# mkdir /var/www/app | core# cd /var/www/app/ | | core# virtualenv-3 -p python3 env | | Running virtualenv with interpreter /usr/local/bin/python3 | Using base prefix '/usr/local' | New python executable in /var/www/app/env/bin/python3 | Also creating executable in /var/www/app/env/bin/python | ERROR: The executable /var/www/app/env/bin/python3 could not be run: | [Errno 13] Permission denied: '/var/www/app/env/bin/python3' | | Well, that makes perfect sense for me, since we're running | some binary not in bin directory, but what is the recommended | way of deploying the app in such situation? | | I'm running on vultr, which provides a non-default disk layout: | | core# mount | /dev/sd0a on / type ffs (local) | /dev/sd0d on /usr/local type ffs (local, nodev, wxallowed) | | Thanks for any suggestions. | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: APU2 and Spectre
On Sat, Aug 25, 2018 at 06:08:49PM +0300, Consus wrote: > Hi, > > Seems like APU2 board is vulnerable to Spectre: > > $ uname -r > 6.3 > $ dmesg | grep cpu0 | grep AMD > cpu0: AMD GX-412TC SOC, 998.27 MHz > $ git clone https://github.com/crozone/SpectrePoC > $ cd SpectrePoC > $ gmake > $ ./spectre.out 85 > Using a cache hit threshold of 85. > Build: RDTSCP_SUPPORTED MFENCE_SUPPORTED CLFLUSH_SUPPORTED > INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED > Reading 40 bytes: > Reading at malicious_x = 0xffeff180... Success: 0x54=’T’ score=2 > Reading at malicious_x = 0xffeff181... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffeff182... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffeff183... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffeff184... Success: 0x4D=’M’ score=2 > Reading at malicious_x = 0xffeff185... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffeff186... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffeff187... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffeff188... Success: 0x63=’c’ score=2 > Reading at malicious_x = 0xffeff189... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffeff18a... Success: 0x57=’W’ score=2 > Reading at malicious_x = 0xffeff18b... Success: 0x6F=’o’ score=2 > Reading at malicious_x = 0xffeff18c... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffeff18d... Success: 0x64=’d’ score=2 > Reading at malicious_x = 0xffeff18e... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffeff18f... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffeff190... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffeff191... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffeff192... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffeff193... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffeff194... Success: 0x53=’S’ score=2 > Reading at malicious_x = 0xffeff195... Success: 0x71=’q’ score=2 > Reading at malicious_x = 0xffeff196... Success: 0x75=’u’ score=2 > Reading at malicious_x = 0xffeff197... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffeff198... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffeff199... Success: 0x6D=’m’ score=2 > Reading at malicious_x = 0xffeff19a... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffeff19b... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffeff19c... Success: 0x68=’h’ score=2 > Reading at malicious_x = 0xffeff19d... Success: 0x20=’ ’ score=2 > Reading at malicious_x = 0xffeff19e... Success: 0x4F=’O’ score=2 > Reading at malicious_x = 0xffeff19f... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffeff1a0... Success: 0x73=’s’ score=2 > Reading at malicious_x = 0xffeff1a1... Success: 0x69=’i’ score=2 > Reading at malicious_x = 0xffeff1a2... Success: 0x66=’f’ score=2 > Reading at malicious_x = 0xffeff1a3... Success: 0x72=’r’ score=2 > Reading at malicious_x = 0xffeff1a4... Success: 0x61=’a’ score=2 > Reading at malicious_x = 0xffeff1a5... Success: 0x67=’g’ score=2 > Reading at malicious_x = 0xffeff1a6... Success: 0x65=’e’ score=2 > Reading at malicious_x = 0xffeff1a7... Success: 0x2E=’.’ score=2 > > I've double-checked output of syspatch(1) and fw_update(1) but no > pending updates exist. Am I missing something or there is no mitigation > for this AMD CPU family? > That's spectre v1 IIRC. And yes, AMD is susceptible. Someone will need to do the work to move the lfence changes into llvm/clang (maybe that's already done) and you'll need an AMD cpu with the MSR to treat lfence as serializing (that is already committed, but you obviously need that CPU capability). -ml
Deploy Django app - strategy?
I'm deploying a Django app on OpenBSD 6.3 and I'm strugging to wrap my head around the best practices here. On Linux we just bootstrap virtualenv in home directory and start uwsgi (or altenative), but on OpenBSD it seems to be a bit more complicated: core# mkdir /var/www/app core# cd /var/www/app/ core# virtualenv-3 -p python3 env Running virtualenv with interpreter /usr/local/bin/python3 Using base prefix '/usr/local' New python executable in /var/www/app/env/bin/python3 Also creating executable in /var/www/app/env/bin/python ERROR: The executable /var/www/app/env/bin/python3 could not be run: [Errno 13] Permission denied: '/var/www/app/env/bin/python3' Well, that makes perfect sense for me, since we're running some binary not in bin directory, but what is the recommended way of deploying the app in such situation? I'm running on vultr, which provides a non-default disk layout: core# mount /dev/sd0a on / type ffs (local) /dev/sd0d on /usr/local type ffs (local, nodev, wxallowed) Thanks for any suggestions.
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
On Sun, Aug 26, 2018 at 05:50:02PM +0200, David Bern wrote: > On Sun, 26 Aug 2018 15:52:48 +0200 > Patrick Wildt wrote: > > > On the MacchiatoBin we don't support the onboard ethernet yet. On the > > EspressoBin we do support the ethernet controller, but the connected > > switch is a mess that I don't dare to support. Got other stuff to do. > > Though I am working on partial EspressoBin support for the upcoming > > Turris Mox. > > Interesting. I was about to place an order on a MacchiatoBin. > What is biggest reason to why the ethernet is not supported yet? > We were waiting on you to write it. If you can obtain the design spec for the Armada7k8k board (which mcbin is) from Marvell, you should be able to crank out the NIC driver for it. Sarcasm aside, patches are welcome. That said, mcbin with either a usb NIC or if you need 10G, drop in an Intel x520 in there and you're set. +--+ Carlos
Re: getting scrollback buffer on OpenBSD 6.3
On Aug 26, 2018 12:40 PM, Alceu Rodrigues de Freitas Junior wrote: > > Hello folks, > > I'm running OpenBSD 6.3 over a Aspire One netbook, and looking for > enabling the "scrollback buffer" mentioned in the related FAQ > (http://www.openbsd.org/faq/faq7.html#Scrollback). > > Unfortunately, it doesn't mention which combination of platforms and > hardware combinations it is supposed to work, neither mentions how to > get a kernel with such feature enabled. > > I tried to Google some info about it, but couldn't find anything that > helped. > > How can I check if it should be working? SHIFT+PgUp doesn't work. > > How can I check if the running kernel that I have (GENERIC.MP#107 amd64) > already has the option compiled? > > If not, what do I need to enable in the kernel to have the scrollback > buffer enabled? > > Thanks in advance. > I'm guessing dmesg | grep drm Should help since it won't work with inteldrm nor radeondrm.
Re: SuperMicro A2SDi-4C-HLN4F
On August 25, 2018 1:59:55 PM GMT+02:00, Rupert Gallagher wrote: > wrote: > >> This vendor addresses hardware & firmware faults like the other >enterprise vendors, they DON'T past year two. BIOS and BMC firmwares >are not updated after this even with the long term lifetime products, >you are on your own! > >On bios and ipmi updates, you can download and apply them yourself. For >advanced bios updates, there is a licence you can purchase, as you do >with Dell and HP. > >On warranty, they are in line with the industry standards: > >https://www.supermicro.com/support/Warranty/ > >On open source, they work with the community, well enough to have a >cetified list of compatible systems: > >https://www.supermicro.com/support/faqs/os.cfm > >When you are in business, you do not want to go back to the drawing >board each time. You need a platform where to build your own services. >If you have to develop disk and keyboard drivers, and you are told off >from the support mailing list, then the OS is worth nothing to you. - That there is no current support, does not mean there will never be. - misc@ is not a support mailing list. In fact, there is none. That does not, however, mean that you can't get help from there. >OpenBSD is not ready for enterprise. By some definition of "for enterprise", sure. /Alexander > >Your faithfull troll.
getting scrollback buffer on OpenBSD 6.3
Hello folks, I'm running OpenBSD 6.3 over a Aspire One netbook, and looking for enabling the "scrollback buffer" mentioned in the related FAQ (http://www.openbsd.org/faq/faq7.html#Scrollback). Unfortunately, it doesn't mention which combination of platforms and hardware combinations it is supposed to work, neither mentions how to get a kernel with such feature enabled. I tried to Google some info about it, but couldn't find anything that helped. How can I check if it should be working? SHIFT+PgUp doesn't work. How can I check if the running kernel that I have (GENERIC.MP#107 amd64) already has the option compiled? If not, what do I need to enable in the kernel to have the scrollback buffer enabled? Thanks in advance.
Re: netstat - process names
On 26/08/2018 14:27, Claudio Jeker wrote: What linux offers is at best best-effort and sometimes wrong. I was actually looking for a Linux netstat -tpna equivalent, but the trick with fstat is better. Thanks for the background explaination - it was very helpful. Best regards, Chris
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
On Sun, 26 Aug 2018 15:52:48 +0200 Patrick Wildt wrote: > On the MacchiatoBin we don't support the onboard ethernet yet. On the > EspressoBin we do support the ethernet controller, but the connected > switch is a mess that I don't dare to support. Got other stuff to do. > Though I am working on partial EspressoBin support for the upcoming > Turris Mox. Interesting. I was about to place an order on a MacchiatoBin. What is biggest reason to why the ethernet is not supported yet? /David
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
On Sun, Aug 26, 2018 at 11:00:26AM +, Stuart Henderson wrote: > On 2018-08-26, Carlos López wrote: > > > > > > On 26/08/2018 11:46, Joel Wirāmu Pauling wrote: > >> netboot works fine. However almost all of the Arm platforms including > >> the Rpi3 make terrible gateways and in general l3 packet path > >> machines. > >> > >> I have a bunch of various SBC and they all suck pretty bad for network > >> tasks. Fine for random server tasks but don't put them in your network > >> path unless you like artificial bottlenecks. > >> > >> The Machiattobin and/or Espressobin platforms are probably the best > >> for network appliance usage. I haven't got one to see if Openbsd works > >> on them at all tho. > >> > >> > > > > Uhmm ... Interesting point Joel ... Searching both SBC, maybe > > Espressobin is best option than Machiattobin ... > > > > Has anyone tried any of them? > > The MACCHIATObin is listed on arm64.html as having some support, the > ESPRESSObin isn't. On the MacchiatoBin we don't support the onboard ethernet yet. On the EspressoBin we do support the ethernet controller, but the connected switch is a mess that I don't dare to support. Got other stuff to do. Though I am working on partial EspressoBin support for the upcoming Turris Mox. That said, if 32-bit ARM is OK look at the Clearfog Base. If you're willing to spend a bit more, SolidRun has nice 64-bit machines. But on those we still need to write the ethernet driver. Patrick
Re: netstat - process names
On Sun, Aug 26, 2018 at 01:19:05PM +0100, he...@ezaquarii.com wrote: > Hi, > > I'm looking for a way to see which processes are listening > on incoming tcp/udp connections. > > So, here is my output of netstat -f inet -p udp -l > > Proto Recv-Q Send-Q Local Address Foreign Address(state) > udp 0 0 core.5022 lithium.constant.ntp > udp 0 0 core.8806 hydrogen.constan.ntp > udp 0 0 core.21164 helium.constant..ntp > udp 0 0 *.**.* > udp 0 0 *.**.* > > First, what does it mean *.* *.* in last 2 entries. Those sockets are not bound or connected. This is possible with UDP sockets since you can use for example sendto(2) without doing a bind(2) or connect(2) call beforehands. There are some daemons that do this (dhclient, slaacd). > Second, how can I verify what process is listening on ports > 5022,8806 and 21164? > This is not possible since more than one process can be listening on a socket (since file descriptors can be shared). You need to use fstat(1) for this. What linux offers is at best best-effort and sometimes wrong. -- :wq Claudio
Re: netstat - process names
Hi, > I'm looking for a way to see which processes are listening > on incoming tcp/udp connections. fstat | grep internet > Second, how can I verify what process is listening on ports > 5022,8806 and 21164? fstat | grep -e ":5022" -e ":8806" -e "21164"
netstat - process names
Hi, I'm looking for a way to see which processes are listening on incoming tcp/udp connections. So, here is my output of netstat -f inet -p udp -l Proto Recv-Q Send-Q Local Address Foreign Address(state) udp 0 0 core.5022 lithium.constant.ntp udp 0 0 core.8806 hydrogen.constan.ntp udp 0 0 core.21164 helium.constant..ntp udp 0 0 *.**.* udp 0 0 *.**.* First, what does it mean *.* *.* in last 2 entries. Second, how can I verify what process is listening on ports 5022,8806 and 21164? Best regards, Chris
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
Hi Carlos, i have a similar requirement and i am considering testing a banana pi router at this moment. On Sun, 26 Aug 2018, 11:30 am Carlos López, wrote: > Hi all, > > I am considering to buy an ARM based device to use it with OpenBSD as > a personal/portable firewall, IDS and Tor gateway. > > My only requirements are: > > a/ OpenBSD well hardware's supported > b/ Best network throughput > > It seems Raspberry 3 B+ maybe the best option, but I am not pretty sure. > > Any advice? > > -- > Greetings, > C. L. Martinez > >
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
Still IME best bang for buck is n3160 ATOM based mini-pc's there are several vendors (Jetway/Qotom) and you can get an AES-NI capable 4 core machine with dual NICs that will do 5Gbit Duplex on the nose for less than 90$ USD. I know intel isn't the flavour of the month, but these machines lack Management Engine or SMT - which at least makes them slightly less dire than more beefy SoC's from Chipzilla. On 26 August 2018 at 23:00, Stuart Henderson wrote: > On 2018-08-26, Carlos López wrote: >> >> >> On 26/08/2018 11:46, Joel Wirāmu Pauling wrote: >>> netboot works fine. However almost all of the Arm platforms including >>> the Rpi3 make terrible gateways and in general l3 packet path >>> machines. >>> >>> I have a bunch of various SBC and they all suck pretty bad for network >>> tasks. Fine for random server tasks but don't put them in your network >>> path unless you like artificial bottlenecks. >>> >>> The Machiattobin and/or Espressobin platforms are probably the best >>> for network appliance usage. I haven't got one to see if Openbsd works >>> on them at all tho. >>> >>> >> >> Uhmm ... Interesting point Joel ... Searching both SBC, maybe >> Espressobin is best option than Machiattobin ... >> >> Has anyone tried any of them? > > The MACCHIATObin is listed on arm64.html as having some support, the > ESPRESSObin isn't. > > If ARM isn't an absolute requirement, I think one of the smaller Octeon > machines (probably EdgeRouter Lite or USG) is likely to be a better choice > for your intended use, and may also be easier to buy locally than some of > the ARM development platforms. https://www.openbsd.org/octeon.html > >
Re: SuperMicro A2SDi-4C-HLN4F
On 2018-08-26, Mihai Popescu wrote: >> OpenBSD is not ready for enterprise. > > Fantastic intuition here [1]. > > [1] https://marc.info/?l=openbsd-misc&m=153385998722067&w=2 > > Would you mind fixing your thread headers please? My killfile entry for threads with 'protonmail.com' in references doesn't work very well otherwise ;)
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
On 2018-08-26, Carlos López wrote: > > > On 26/08/2018 11:46, Joel Wirāmu Pauling wrote: >> netboot works fine. However almost all of the Arm platforms including >> the Rpi3 make terrible gateways and in general l3 packet path >> machines. >> >> I have a bunch of various SBC and they all suck pretty bad for network >> tasks. Fine for random server tasks but don't put them in your network >> path unless you like artificial bottlenecks. >> >> The Machiattobin and/or Espressobin platforms are probably the best >> for network appliance usage. I haven't got one to see if Openbsd works >> on them at all tho. >> >> > > Uhmm ... Interesting point Joel ... Searching both SBC, maybe > Espressobin is best option than Machiattobin ... > > Has anyone tried any of them? The MACCHIATObin is listed on arm64.html as having some support, the ESPRESSObin isn't. If ARM isn't an absolute requirement, I think one of the smaller Octeon machines (probably EdgeRouter Lite or USG) is likely to be a better choice for your intended use, and may also be easier to buy locally than some of the ARM development platforms. https://www.openbsd.org/octeon.html
Re: wifi gui manager
Stefan Sperling wrote: > On Wed, Aug 22, 2018 at 06:38:11PM -0700, Chris Bennett wrote: > > Well, there are probably additional reasons too, but my father > > happily runs OpenBSD. Of course, he needs to be able to turn the > > computer off. > > I would recommend using doas(1) to grant 'shutdown' to a particular > user. You don't want to run a web browser from an account in the > operator group. An alternative is to just press the power button for half a second. I have yet to encounter hardware running OpenBSD that won't shut down cleanly this way, as APM/ACPI support has been stellar for me. Logging out first would be advisable though, /me thinks.
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
On 26/08/2018 11:46, Joel Wirāmu Pauling wrote: netboot works fine. However almost all of the Arm platforms including the Rpi3 make terrible gateways and in general l3 packet path machines. I have a bunch of various SBC and they all suck pretty bad for network tasks. Fine for random server tasks but don't put them in your network path unless you like artificial bottlenecks. The Machiattobin and/or Espressobin platforms are probably the best for network appliance usage. I haven't got one to see if Openbsd works on them at all tho. Uhmm ... Interesting point Joel ... Searching both SBC, maybe Espressobin is best option than Machiattobin ... Has anyone tried any of them? Greetings, C. L. Martinez
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
netboot works fine. However almost all of the Arm platforms including the Rpi3 make terrible gateways and in general l3 packet path machines. I have a bunch of various SBC and they all suck pretty bad for network tasks. Fine for random server tasks but don't put them in your network path unless you like artificial bottlenecks. The Machiattobin and/or Espressobin platforms are probably the best for network appliance usage. I haven't got one to see if Openbsd works on them at all tho. On 26 August 2018 at 21:33, Alfredo “Fred” Vogel wrote: > Hi hola, > The raspi is fiddly for installing openbsd. One needs a special usb cable to > install obsd because there is no driver for the sdcard booting device! > Regards > Alfredo > On 26 Aug 2018, 10:30 +0100, Carlos López , wrote: >> Hi all, >> >> I am considering to buy an ARM based device to use it with OpenBSD as >> a personal/portable firewall, IDS and Tor gateway. >> >> My only requirements are: >> >> a/ OpenBSD well hardware's supported >> b/ Best network throughput >> >> It seems Raspberry 3 B+ maybe the best option, but I am not pretty sure. >> >> Any advice? >> >> -- >> Greetings, >> C. L. Martinez >>
Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
Hi hola, The raspi is fiddly for installing openbsd. One needs a special usb cable to install obsd because there is no driver for the sdcard booting device! Regards Alfredo On 26 Aug 2018, 10:30 +0100, Carlos López , wrote: > Hi all, > > I am considering to buy an ARM based device to use it with OpenBSD as > a personal/portable firewall, IDS and Tor gateway. > > My only requirements are: > > a/ OpenBSD well hardware's supported > b/ Best network throughput > > It seems Raspberry 3 B+ maybe the best option, but I am not pretty sure. > > Any advice? > > -- > Greetings, > C. L. Martinez >
Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64
Hi all, I am considering to buy an ARM based device to use it with OpenBSD as a personal/portable firewall, IDS and Tor gateway. My only requirements are: a/ OpenBSD well hardware's supported b/ Best network throughput It seems Raspberry 3 B+ maybe the best option, but I am not pretty sure. Any advice? -- Greetings, C. L. Martinez
Re: SuperMicro A2SDi-4C-HLN4F
Popescu, obsd does not always work. Hiding the bugs, instead of showing them on git issues or bugzilla, it does not make obsd any better. Sent from ProtonMail Mobile
iridium --enable-unveil and extensions
Hi all I think i must be missing something, i am unable to get extensions working in Iridium with "--enable-unveil". unveil.main has "~/.config rwc" and i thought extensions live under ".config/iridium/Default/Extensions" so thought maybe that should be enough, its not. as a hack i added "~/.config rwc" to all unveil files under /etc/iridium, but that didn't work. (they are removed now) Once i can figure out how to get an extension working, i would like to tighten in unveil so only it can work. The output to stdout/stderr didn't help, is there another log file? Cheers Adam
Re: Atom CPU is clear of L1TF
https://marc.info/?l=openbsd-misc&m=153443566603373&w=2 Sent from ProtonMail Mobile On Sat, Aug 25, 2018 at 22:07, Rupert Gallagher wrote: > The fact that obsd works on your x7-Z8750 says nothing on the fact that it > does not work on my c3558. > > On Sat, Aug 25, 2018 at 15:48, Benjamin Baier wrote: > >> On Sat, 25 Aug 2018 07:10:14 + >> Rupert Gallagher wrote: >> >>> While Intel Core and Xeon are affected by L1TF, Atom CPUs (c3000) are clear >>> of it. Applying the patch to Cores and Xeons basically turns those CPUs >>> into Atoms. It is a shame that the self-appointed "most secure OS" does not >>> run on such processors. >> >> What? Atom X works well, why wouldn't it run on C3000? >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: Intel(R) Atom(TM) x7-Z8750 CPU @ 1.60GHz, 1600.36 MHz >> >>> Your faithful troll. >> I see.
