Re: problems setting up PORTS_PRIVSEP
The man page of bsd.port.mk, particular PORTS_PRIVSEP
provides this suggestion
'permit nopass setenv {} user cmd pkg_add'
I don't know much about what pkg_add can do, but when
building packages with many dependencies, password prompt
greets for every dependency, persist option doesn't work
across the dependencies for the above command,
so it becomes a pain in the ass.
I think persist doesn't work because of the setenv part,
since it is different for every package/sub-package
What do you suggest?
Re: Faking the same LAN over the Internet
On Tue, Mar 31, 2020 at 10:34:39AM +0100, Chris Rawnsley wrote: > In the period of The Great Isolation, a friend and I wish to play > a game that has LAN-only multiplayer. We, however, live in different > locations and, more importantly, different LANs. An often cited > approach to solving this is to set up a VPN and connect the two > devices to it. This requires that both devices run a VPN client > that connects to the third device that manages the connection. And > then, hey presto! You have a "LAN". > > The complication I have found is that we are both using a Nintendo > Switch (NinSw) and this device comes without a VPN client. Initially, > I thought it would be possible to use a VPN client on a computer > which was wired in over Ethernet and then share the wireless to the > NinSw. This setup would be mirrored on the other side. The diagram > below tries to make this clearer. Search for "Where my thinking" > to skip over this. > > > || > || .. > || ) ) ) |:| |:| > || `' > .---/::\[NinSw] > | [laptop] > | >[VPN] > | > | \/ > | _\__/_ > `-| ... |[uplink]// mirrored on the other side > `` > [gateway] > > > Where my thinking comes stuck is how the wired connection is shared > to the NinSw over wireless. The laptop, running MacOS in the case > of my friend, will setup its own NAT to isolate the wireless > connections from the uplink. The NinSw is then unable to receive > an IP from the VPN and therefore not appear as part of the same > network. > > Ignoring the particular case of how "Internet Connection Sharing" > works on MacOS, would it be possible to setup some "VPN bridge" > (yes, I made that up) on OpenBSD where it handles the details of > the VPN connection but forwards the IP address to another device? > > If anyone has more insight into this and can point me in the right > direction I would be grateful. Similarly if there's been a mistake > in my thinking please point it out as that could help too. I'm using OpenBSD IPSec to connect two LAN's (at two locations, with different ISP's). Have a look at this article: https://openbsd.fandom.com/wiki/OpenBSD_IPSec_made_easy This setup has worked flawlessly for me for years now, only occasionally broken whenever one or both of the ISP's decide to change my dynamically assigned IP's, upon which I'll have to manually rename one file and restart the IPSec service. (It happens so seldom that I haven't bothered looking into how to automate it.) This setup may require both you and your friend to have an internet facing OpenBSD gateway situated at/in front of [uplink]. Nice ASCII btw. Cheers, Erling > > -- > Chris Rawnsley > > P.S. the game in question is Civilization 6 and, yes, they very > annoyingly restricted it to LAN-only multiplayer...
Touchpad 2-finger scrolling problem / Feature request
I was trying to get two-finger scrolling working on my Dell Inspiron 15-3567 laptop. Tap to click would work as well as left and right buttons but it's quite troublesome not to take advantage of atleast a scrolling gesture. Touchpad works perfectly on fedora. As far as I can tell, touchpad is being loaded via wsmouse despite trying to load it with synaptics on /etc/xorg.conf. With many configuration attempts, I came to a conclusion that the hardware might not be supported. I would greatly appreciate suggestions or workarounds I'm not aware of, otherwise, I'll leave it here as a feature request. Here is my dmesg and xorg.conf: https://pastebin.com/eqTbCnN2; target="blank"> Link to dmesg: https://pastebin.com/eqTbCnN2 https://pastebin.com/V42G0UZd;> Link to xorg.conf: https://pastebin.com/V42G0UZd Also, here is my wsconsctl and Xorg.0.log: https://pastebin.com/CYuRNHz1; target="blank"> Link to ws/xorg log: https://pastebin.com/CYuRNHz1
Re: npppd pptp hangs
On Mon, 30 Mar 2020 14:33:46 +0300 Vitaliy Makkoveev wrote: > On Mon, Mar 30, 2020 at 02:28:08PM +0300, Vitaliy Makkoveev wrote: > > You have pipex(4) disabled. Is it still hangs with disabled > > pipex(4)? As I discovered > > (https://marc.info/?t=15852997681=1=2), npppd with pipex(4) > > enabled and non-NULL "idle-timeout" option will crash kernel. You > > can disable this option in yout npppd.conf an reenable pipex(4). > > Looks like crashes should gone. > And don't use pppac(4) with pipex enabled, use pppx(4). Crash you > reported https://marc.info/?t=15850622592=1=2 is actual for > pppac(4). > Thanks for the instruction. I have: - left net.pipex.enable=1 - replaced tun1 with pppx0 in npppd.conf - removed 'pipex no' from npppd.conf So far so good, I'll send update if I experience further hangs. The instruction on pppx(4) you gave me came as surprising news to me. I have been using npppd since it still had undocumented 'old style' config. Once npppd.conf got its manpage (was it 5.3?) I've set up tun1 as PPTP interface and it worked great with up to ~20 clients all these years. I was very satisfied that all PPTP traffic went through single interface (as opposed to my previous setup with poptop which created separate tun interface for each session), as I had the ability to graph its traffic from SNMP data. I guess I was 'holding it wrong' all this time, and yet it worked well :) Thank you once again. -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Faking the same LAN over the Internet
In the period of The Great Isolation, a friend and I wish to play a game that has LAN-only multiplayer. We, however, live in different locations and, more importantly, different LANs. An often cited approach to solving this is to set up a VPN and connect the two devices to it. This requires that both devices run a VPN client that connects to the third device that manages the connection. And then, hey presto! You have a "LAN". The complication I have found is that we are both using a Nintendo Switch (NinSw) and this device comes without a VPN client. Initially, I thought it would be possible to use a VPN client on a computer which was wired in over Ethernet and then share the wireless to the NinSw. This setup would be mirrored on the other side. The diagram below tries to make this clearer. Search for "Where my thinking" to skip over this. || || .. || ) ) ) |:| |:| || `' .---/::\[NinSw] | [laptop] | [VPN] | | \/ | _\__/_ `-| ... |[uplink]// mirrored on the other side `` [gateway] Where my thinking comes stuck is how the wired connection is shared to the NinSw over wireless. The laptop, running MacOS in the case of my friend, will setup its own NAT to isolate the wireless connections from the uplink. The NinSw is then unable to receive an IP from the VPN and therefore not appear as part of the same network. Ignoring the particular case of how "Internet Connection Sharing" works on MacOS, would it be possible to setup some "VPN bridge" (yes, I made that up) on OpenBSD where it handles the details of the VPN connection but forwards the IP address to another device? If anyone has more insight into this and can point me in the right direction I would be grateful. Similarly if there's been a mistake in my thinking please point it out as that could help too. -- Chris Rawnsley P.S. the game in question is Civilization 6 and, yes, they very annoyingly restricted it to LAN-only multiplayer...
Re: Faking the same LAN over the Internet
Sorry for top posting, Would https://openvpn.net/vpn-server-resources/site-to-site-layer-2-bridging-using-openvpn-access-server/ solve your problem? Regards, Erik Op 31-3-2020 om 11:34 schreef Chris Rawnsley: > In the period of The Great Isolation, a friend and I wish to play > a game that has LAN-only multiplayer. We, however, live in different > locations and, more importantly, different LANs. An often cited > approach to solving this is to set up a VPN and connect the two > devices to it. This requires that both devices run a VPN client > that connects to the third device that manages the connection. And > then, hey presto! You have a "LAN". > > The complication I have found is that we are both using a Nintendo > Switch (NinSw) and this device comes without a VPN client. Initially, > I thought it would be possible to use a VPN client on a computer > which was wired in over Ethernet and then share the wireless to the > NinSw. This setup would be mirrored on the other side. The diagram > below tries to make this clearer. Search for "Where my thinking" > to skip over this. > > > || > || .. > || ) ) ) |:| |:| > || `' > .---/::\[NinSw] > | [laptop] > | >[VPN] > | > | \/ > | _\__/_ > `-| ... |[uplink]// mirrored on the other side > `` > [gateway] > > > Where my thinking comes stuck is how the wired connection is shared > to the NinSw over wireless. The laptop, running MacOS in the case > of my friend, will setup its own NAT to isolate the wireless > connections from the uplink. The NinSw is then unable to receive > an IP from the VPN and therefore not appear as part of the same > network. > > Ignoring the particular case of how "Internet Connection Sharing" > works on MacOS, would it be possible to setup some "VPN bridge" > (yes, I made that up) on OpenBSD where it handles the details of > the VPN connection but forwards the IP address to another device? > > If anyone has more insight into this and can point me in the right > direction I would be grateful. Similarly if there's been a mistake > in my thinking please point it out as that could help too. > > > -- > Chris Rawnsley > > P.S. the game in question is Civilization 6 and, yes, they very > annoyingly restricted it to LAN-only multiplayer... > pEpkey.asc Description: application/pgp-keys
Re: openbsd.org - certain https URLs downgraded to http in redirection
Namaste misc, Apologies for the reincarnation of this mail trail. > Sent: Tuesday, February 25, 2020 at 10:40 PM > From: "Constantine A. Murenin" > To: "Vincenzo Nicosia" > Cc: "Stuart Henderson" , "misc@openbsd.org" > > Subject: Re: openbsd.org - certain https URLs downgraded to http in > redirection > > On Tue, 25 Feb 2020 at 04:35, Vincenzo Nicosia wrote: > > > On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote: > > > > [cut] > > > > > > Want https? great. use it. There are times when it's handy to NOT > > > > be obsessed with https (i.e., clock is hosed on your computer). > > > > > > > > So ... unless some developer I really respect (which is just about > > > > all of them1) tells me to change this, I'm not planning on > > > > changing the behavior of the machines. > > > > > > I did object to http->https redirects in the past, but now the web is > > > unusable without working https anyway and the "INSECURE openbsd.org" > > > shown on some browsers *is* a bit of an eyesore ... > > > > > > > IMHO, the fact that corporates (Google) want to dictate what is secure > > and what is not, is not sufficient to force everybody on https, at all > > times. I personally don't give a toss of what Chrome thinks of a > > website and its security (maybe because I have never used Chrome or > > because I quit google searches more than 10 years ago...). > > > > There are many cases where the overhead introduced by https is really > > not worth the extra bit of confidentiality you get. And we are talking > > here of manpages (that are installed in your system anyway) and of > > system sources (that are available for download at any time, even from > > an HTTPS mirror)... > > > > Sorry for the rant, but if I type "http://bring.me.there; I don't want > > to find myself at "https://we.brought.you.somewhere.else;. I am not a > > chimp. I know what I type in my URL box. I know what I expect. And I > > want to be able to serve content via HTTP/1.0 if I need so. > > > > Exactly. > > Folks often forget, or are blissfully unaware, that Google Search itself > still does work over both HTTP (without the S) as well as over the legacy > TLSv1.0 HTTPS, so, the propaganda efforts and the destructive webmaster > advice given by the Google Chrome and Mozilla teams to suppress the > minorities from being able to access the websites is hypocritical, to say > the least. /Do as I say, not as I do./ > > The HTTP and TLSv1.0 traffic is mostly bots, some folks say? Surprise — > many bots are still controlled by good people, used to do various useful > things, so, you're still blocking actual people from a minority class from > having access to your website. Not to mention the older phones and tablets > with hundreds of megabytes of RAM and gigabytes of storage space that were > abandoned by their creators and don't support TLSv1.2 and/or all the newest > ciphers that are deemed to be the best practice today. The sad part is > that the non-profits of today (e.g., Mozilla and Wikipedia) are effectively > brokering the planned obsolescence of all these devices on behalf of the > respective vendors. > > C. > Current situation: https://www.openbsd.org/cgi-bin/man.cgi* -> http://man.openbsd.org/cgi-bin/man.cgi* https://www.openbsd.org/cgi-bin/cvsweb -> http://cvsweb.openbsd.org/cgi-bin/cvsweb http://www.openbsd.org/cgi-bin/man.cgi* -> http://man.openbsd.org/cgi-bin/man.cgi* http://www.openbsd.org/cgi-bin/cvsweb -> http://cvsweb.openbsd.org/cgi-bin/cvsweb What volks here thought I was asking for: https://www.openbsd.org/cgi-bin/man.cgi* -> https://man.openbsd.org/cgi-bin/man.cgi* https://www.openbsd.org/cgi-bin/cvsweb -> https://cvsweb.openbsd.org/cgi-bin/cvsweb http://www.openbsd.org/cgi-bin/man.cgi* -> https://man.openbsd.org/cgi-bin/man.cgi* http://www.openbsd.org/cgi-bin/cvsweb -> https://cvsweb.openbsd.org/cgi-bin/cvsweb What my actual request is: https://www.openbsd.org/cgi-bin/man.cgi* -> https://man.openbsd.org/cgi-bin/man.cgi* https://www.openbsd.org/cgi-bin/cvsweb -> https://cvsweb.openbsd.org/cgi-bin/cvsweb http://www.openbsd.org/cgi-bin/man.cgi* -> http://man.openbsd.org/cgi-bin/man.cgi* http://www.openbsd.org/cgi-bin/cvsweb -> http://cvsweb.openbsd.org/cgi-bin/cvsweb In other words, Current configuration https -> http http -> http Not Intended configuration https -> https http -> https Intended configuration https -> https http -> http Currently, requests arriving on https as well as http ports are redirected to the http port. This effectively downgrades a user-agent from https to http, which I think may not be desirable. In the intended configuration, if a request arrives on the https port, it should be redirected to the https port, and not to the http port. If a request arrives on the http port, it should continue to be redirected to the http port. This nuance is conveyed from the following line in the configuration in my request: ... listen on * port https ... In terms of
Re: nmea0 huge timedelta while system clock is in sync
Martin, I think you misread what is below. Since you won't file a complete bug report with all details, you are on your own. Good luck! Martin wrote: > Still can't find a solution. I'm suspect backup battery. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, March 22, 2020 9:12 PM, Otto Moerbeek wrote: > > > On Sun, Mar 22, 2020 at 08:26:25PM +, Martin wrote: > > > > > Hello Otto, > > > I can't share any coordinates, but after analyzing NMEA messages from > > > receiver I see the correct UTC time in first field of $GPGGA, $PQXFI > > > (Qualcomm extended fix information), $GNSNS sentences. In repeating > > > sentences time data changes every second as it should be. System's time > > > in sync with NTP pool currently, so it has minimum delta possible. > > > $GPGGA,194359.00,coordinates,. > > > $PQXFI,194359.00,coordinates,. > > > $GNSNS,194359.00,coordinates,. > > > ... > > > $GPRMC,194359.00,coordinates,. > > > ... > > > $GPGGA,194400.00,coordinates,. > > > $PQXFI,194400.00,coordinates,. > > > $GNSNS,194400.00,coordinates,. > > > ... > > > $GPRMC,194400.00,coordinates,. > > > > Double sigh. The datestamp in the $GPRMC message is important. > > > > But I give up, you are only making things difficult. > > > > -Otto > > > > > Any way to perform manual 'reset' timedelta to any 'default' value? > > > Martin > > > ‐‐‐ Original Message ‐‐‐ > > > On Sunday, March 22, 2020 3:28 PM, Otto Moerbeek o...@drijf.net wrote: > > > > > > > On Sun, Mar 22, 2020 at 03:22:40PM +, Martin wrote: > > > > > > > > > The position is absolutely correct. I forgot to mention I changed > > > > > Latitude and Longitude by different values. > > > > > The timedelta is incorrect and it's only the question why. > > > > > I missed a moment when huge time skew appeared. Just system clock was > > > > > changed significantly to incorrect value. Now ntpd.conf set to NTP > > > > > pool, but hope I can fix radioclocks. > > > > > Martin > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > On Sunday, March 22, 2020 12:54 PM, Otto Moerbeek o...@drijf.net > > > > > wrote: > > > > > > > > > > > On Sun, Mar 22, 2020 at 12:19:39PM +, Martin wrote: > > > > > > > > > > > > > hw.sensors.nmea0.indicator0=On (Signal), OK > > > > > > > hw.sensors.nmea0.timedelta0=619313970.981246 secs (GPS > > > > > > > autonomous), OK, Sun Mar 22 12:47:08.981 > > > > > > > ^^ > > > > > > > hw.sensors.nmea0.angle0=10.0 degrees (Latitude), OK > > > > > > > hw.sensors.nmea0.angle1=20.0 degrees (Longitude), OK > > > > > > > hw.sensors.nmea0.distance0=30.0 m (Altitude), OK > > > > > > > hw.sensors.nmea0.velocity0=0.000 m/s (Ground speed), OK > > > > > > > It works for about two years before like a charm, but now > > > > > > > timedelta 619313970.981246 secs. > > > > > > > Tried to change GPS receiver, no effect. > > > > > > > Martin > > > > > > > > > > > > You position is also suspect. Can you run cu on the port the GPS is > > > > > > atteched to and get a snippet of the output? > > > > > > -Otto > > > > > > > > Sigh, you are making troubleshooting this harder than needed by > > > > editing output without saying so. Also, I asked for an NMEA output > > > > log. > > > > Uncomment your ldattach line in /etc/ttys > > > > kill -1 1 > > > > cu -l ttyXX -s 4800 > > > > (Change speed to match your device). Without log I cannot help. > > > > -Otto > >
Re: nmea0 huge timedelta while system clock is in sync
Still can't find a solution. I'm suspect backup battery. ‐‐‐ Original Message ‐‐‐ On Sunday, March 22, 2020 9:12 PM, Otto Moerbeek wrote: > On Sun, Mar 22, 2020 at 08:26:25PM +, Martin wrote: > > > Hello Otto, > > I can't share any coordinates, but after analyzing NMEA messages from > > receiver I see the correct UTC time in first field of $GPGGA, $PQXFI > > (Qualcomm extended fix information), $GNSNS sentences. In repeating > > sentences time data changes every second as it should be. System's time in > > sync with NTP pool currently, so it has minimum delta possible. > > $GPGGA,194359.00,coordinates,. > > $PQXFI,194359.00,coordinates,. > > $GNSNS,194359.00,coordinates,. > > ... > > $GPRMC,194359.00,coordinates,. > > ... > > $GPGGA,194400.00,coordinates,. > > $PQXFI,194400.00,coordinates,. > > $GNSNS,194400.00,coordinates,. > > ... > > $GPRMC,194400.00,coordinates,. > > Double sigh. The datestamp in the $GPRMC message is important. > > But I give up, you are only making things difficult. > > -Otto > > > Any way to perform manual 'reset' timedelta to any 'default' value? > > Martin > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, March 22, 2020 3:28 PM, Otto Moerbeek o...@drijf.net wrote: > > > > > On Sun, Mar 22, 2020 at 03:22:40PM +, Martin wrote: > > > > > > > The position is absolutely correct. I forgot to mention I changed > > > > Latitude and Longitude by different values. > > > > The timedelta is incorrect and it's only the question why. > > > > I missed a moment when huge time skew appeared. Just system clock was > > > > changed significantly to incorrect value. Now ntpd.conf set to NTP > > > > pool, but hope I can fix radioclocks. > > > > Martin > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Sunday, March 22, 2020 12:54 PM, Otto Moerbeek o...@drijf.net wrote: > > > > > > > > > On Sun, Mar 22, 2020 at 12:19:39PM +, Martin wrote: > > > > > > > > > > > hw.sensors.nmea0.indicator0=On (Signal), OK > > > > > > hw.sensors.nmea0.timedelta0=619313970.981246 secs (GPS autonomous), > > > > > > OK, Sun Mar 22 12:47:08.981 > > > > > > ^^ > > > > > > hw.sensors.nmea0.angle0=10.0 degrees (Latitude), OK > > > > > > hw.sensors.nmea0.angle1=20.0 degrees (Longitude), OK > > > > > > hw.sensors.nmea0.distance0=30.0 m (Altitude), OK > > > > > > hw.sensors.nmea0.velocity0=0.000 m/s (Ground speed), OK > > > > > > It works for about two years before like a charm, but now timedelta > > > > > > 619313970.981246 secs. > > > > > > Tried to change GPS receiver, no effect. > > > > > > Martin > > > > > > > > > > You position is also suspect. Can you run cu on the port the GPS is > > > > > atteched to and get a snippet of the output? > > > > > -Otto > > > > > > Sigh, you are making troubleshooting this harder than needed by > > > editing output without saying so. Also, I asked for an NMEA output > > > log. > > > Uncomment your ldattach line in /etc/ttys > > > kill -1 1 > > > cu -l ttyXX -s 4800 > > > (Change speed to match your device). Without log I cannot help. > > > -Otto
Re: openbsd.org - certain https URLs downgraded to http in redirection
What you say makes no sense for one simple reason: man.cgi (and cvsweb) moved out of www.openbsd.org ages ago, prior to there being any https on www.openbsd.org (correct me if I'm wrong here), so, there should not be any legitimate organic links that would be linking to https towards www.openbsd.org/cgi-bin/ in the first place; as such, there's little reason to change anything here. C. On Tue, 31 Mar 2020 at 08:00, Aham Brahmasmi wrote: > Namaste misc, > > Apologies for the reincarnation of this mail trail. > > > Sent: Tuesday, February 25, 2020 at 10:40 PM > > From: "Constantine A. Murenin" > > To: "Vincenzo Nicosia" > > Cc: "Stuart Henderson" , "misc@openbsd.org" < > misc@openbsd.org> > > Subject: Re: openbsd.org - certain https URLs downgraded to http in > redirection > > > > On Tue, 25 Feb 2020 at 04:35, Vincenzo Nicosia > wrote: > > > > > On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote: > > > > > > [cut] > > > > > > > > Want https? great. use it. There are times when it's handy to NOT > > > > > be obsessed with https (i.e., clock is hosed on your computer). > > > > > > > > > > So ... unless some developer I really respect (which is just about > > > > > all of them1) tells me to change this, I'm not planning on > > > > > changing the behavior of the machines. > > > > > > > > I did object to http->https redirects in the past, but now the web is > > > > unusable without working https anyway and the "INSECURE openbsd.org" > > > > shown on some browsers *is* a bit of an eyesore ... > > > > > > > > > > IMHO, the fact that corporates (Google) want to dictate what is secure > > > and what is not, is not sufficient to force everybody on https, at all > > > times. I personally don't give a toss of what Chrome thinks of a > > > website and its security (maybe because I have never used Chrome or > > > because I quit google searches more than 10 years ago...). > > > > > > There are many cases where the overhead introduced by https is really > > > not worth the extra bit of confidentiality you get. And we are talking > > > here of manpages (that are installed in your system anyway) and of > > > system sources (that are available for download at any time, even from > > > an HTTPS mirror)... > > > > > > Sorry for the rant, but if I type "http://bring.me.there; I don't want > > > to find myself at "https://we.brought.you.somewhere.else;. I am not a > > > chimp. I know what I type in my URL box. I know what I expect. And I > > > want to be able to serve content via HTTP/1.0 if I need so. > > > > > > > Exactly. > > > > Folks often forget, or are blissfully unaware, that Google Search itself > > still does work over both HTTP (without the S) as well as over the legacy > > TLSv1.0 HTTPS, so, the propaganda efforts and the destructive webmaster > > advice given by the Google Chrome and Mozilla teams to suppress the > > minorities from being able to access the websites is hypocritical, to say > > the least. /Do as I say, not as I do./ > > > > The HTTP and TLSv1.0 traffic is mostly bots, some folks say? Surprise — > > many bots are still controlled by good people, used to do various useful > > things, so, you're still blocking actual people from a minority class > from > > having access to your website. Not to mention the older phones and > tablets > > with hundreds of megabytes of RAM and gigabytes of storage space that > were > > abandoned by their creators and don't support TLSv1.2 and/or all the > newest > > ciphers that are deemed to be the best practice today. The sad part is > > that the non-profits of today (e.g., Mozilla and Wikipedia) are > effectively > > brokering the planned obsolescence of all these devices on behalf of the > > respective vendors. > > > > C. > > > > Current situation: > > https://www.openbsd.org/cgi-bin/man.cgi* -> > http://man.openbsd.org/cgi-bin/man.cgi* > https://www.openbsd.org/cgi-bin/cvsweb -> > http://cvsweb.openbsd.org/cgi-bin/cvsweb > > http://www.openbsd.org/cgi-bin/man.cgi* -> > http://man.openbsd.org/cgi-bin/man.cgi* > http://www.openbsd.org/cgi-bin/cvsweb -> > http://cvsweb.openbsd.org/cgi-bin/cvsweb > > What volks here thought I was asking for: > > https://www.openbsd.org/cgi-bin/man.cgi* -> > https://man.openbsd.org/cgi-bin/man.cgi* > https://www.openbsd.org/cgi-bin/cvsweb -> > https://cvsweb.openbsd.org/cgi-bin/cvsweb > > http://www.openbsd.org/cgi-bin/man.cgi* -> > https://man.openbsd.org/cgi-bin/man.cgi* > http://www.openbsd.org/cgi-bin/cvsweb -> > https://cvsweb.openbsd.org/cgi-bin/cvsweb > > What my actual request is: > > https://www.openbsd.org/cgi-bin/man.cgi* -> > https://man.openbsd.org/cgi-bin/man.cgi* > https://www.openbsd.org/cgi-bin/cvsweb -> > https://cvsweb.openbsd.org/cgi-bin/cvsweb > > http://www.openbsd.org/cgi-bin/man.cgi* -> > http://man.openbsd.org/cgi-bin/man.cgi* > http://www.openbsd.org/cgi-bin/cvsweb -> > http://cvsweb.openbsd.org/cgi-bin/cvsweb > > In other words, > > Current configuration > https -> http > http -> http > >
X11 fails to start on Zotac box
I am trying to get X11 working on a Zotac box with a quad core Celeron processor, ZBOX-CI323NANO with "Intel HD graphics" (no further info). No dice. Starting xenodm from boot results in a hang with a blank screen. Running startx after boot produces some output to stderr and an Xorg log file entry. I am attaching both and the dmesg output. I noticed the entry in the log file *** [ 199.977] (II) The server relies on wscons to provide the list of input devi\ ces. If no devices become available, reconfigure wscons or disable AutoAddDe\ vices. [ 199.977] (II) Loader magic: 0x3c2056ae000 [ 199.977] (II) Module ABI versions: [ 199.977]X.Org ANSI C Emulation: 0.4 [ 199.977]X.Org Video Driver: 24.1 [ 199.977]X.Org XInput driver : 24.1 [ 199.977]X.Org Server Extension : 10.0 [ 199.978] (EE) Fatal server error: [ 199.978] (EE) xf86OpenConsole: No console driver found Supported drivers: wscons Check your kernel's console driver configuration and /dev entries(EE) [ 199.978] (EE) but I am not quite sure what to do about it. Forgot to mention that I am running openbsd 6.6-current (as of 31 March 2020). -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond X11zotac.dmesg Description: Binary data X11zotac.stderr Description: Binary data X11zotac.logfile Description: Binary data
"sendmsg(DHCPREQUEST): Permission denied" in /var/log/messages every 10 minutes
I keep getting this error for my WAN interface. Is it something I should be
worried about? The internet is working just fine. However, I do have a
static IP, so if I introduced some configuration error recently, it might
become a problem if that changes later on.
The relevant part of my pf.conf looks like this:
table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
203.0.113.0/24 }
table persist
set block-policy drop
set loginterface egress
set skip on { lo0 }
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
antispoof quick for { egress $LAN }
block in quick on egress from to any
block return out quick on egress from any to
block quick from
block drop log all
# Force use of local unbound DNS
pass in quick on $LAN proto { udp, tcp } from any to any port domain rdr-to
10.0.0.1 port domain
# Force use of local ntp server
pass in quick on $LAN proto { udp, tcp } from any to any port ntp rdr-to
10.0.0.1 port ntp
pass out quick inet
pass in on $LAN inet
And my hostname.vlan101(WAN):
dhcp inet6 autoconf vnetid 101 parent em0
description "internet"
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
