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: Current snapshot sets fail verification
On 2019-06-20, Andreas Kusalananda Kähäri wrote: > > It seems to have resolved itself. Maybe I just managed to run > sysupgrade while the mirror was updating... > > > On Thu, Jun 20, 2019 at 09:45:50PM +0200, Andreas Kusalananda Kähäri wrote: >> >> That's for amd64, sorry, forgot to mention. >> >> On Thu, Jun 20, 2019 at 09:44:54PM +0200, Andreas Kusalananda Kähäri wrote: >> > With https://cdn.openbsd.org/pub/OpenBSD in /etc/installurl, sysupgrade >> > currently fails: CDN caches are fine for releases, but I strongly recommend a standard mirror for snapshots.
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: network alias on different network
Thank you Claudio!!! That worked. I am always grateful for the valuable knowledge in the Open BSD community. Thanks, Victor -Original Message- From: Claudio Jeker Sent: Thursday, June 20, 2019 2:31 PM To: Victor Camacho Cc: misc@openbsd.org Subject: Re: network alias on different network On Thu, Jun 20, 2019 at 07:05:57PM +, Victor Camacho wrote: > Hi, > > Using OpenBSD 6.4 and I wanted to run some alias ip addresses on one of the > interfaces. > My question is, can I use a different network as an alias? > > Example: > fw3# more hostname.bge0 > inet 10.2.0.1 255.255.0.0 > inet alias 10.2.1.1 255.255.255.255 > inet alias 10.2.2.1 255.255.255.255 > inet alias 10.2.4.1 255.255.255.255 > inet alias 10.2.6.1 255.255.255.255 > inet alias 172.17.11.1 255.255.255.255 > > I am having a problem pinging on the 172.17.11.0 network. > Ping 172.17.11.1 > Responds, but nothing else on the network. > I saw one thing on the internet that said 'alias' has to be on the same > network, but this was not specific as far as age and what operating system. > To me a router, routes. > Any clarification or better way to handle this would be appreciated. > You need to add the 172.17.11.1 with the correct netmask. The 255.255.255.255 netmask will not allow it to see any other system on that net. The 255.255.255.255 netmask should only be used for additional IPs that are already covered by an other IP address on that interface. Because of this outgoing traffic will use 10.2.0.1 as local IP address an not one of the other (10.2.1.1, 10.2.2.1, ...) unless explicitly bound. When using two different networks on the same interface just configure them the usual way (alias is just telling ifconfig not to replace the first IP address on the interface and instead add another one). > Here is the routing table (with public ip and mac addresses changed or > obscured): > > fw3# route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > defaultx.x.x.109 UGS 261 23105124 - 8 dc0 > 224/4 127.0.0.1 URS00 32768 8 lo0 > 10.2/1610.2.0.1 UCn 31 3623 - 4 bge0 > 10.2.0.1 00:16:41:ed:dd:47 UHLl 026952 - 1 bge0 > 10.2.1.1 00:16:41:ed:dd:47 UHLl 0 175419 - 1 bge0 > 10.2.1.1/3210.2.1.1 UCn00 - 4 bge0 > 10.2.1.11 b4:fb:e4:2c:5b:4d UHLc 0 249998 - 3 bge0 > 10.2.1.200 e8:36:17:6e:89:67 UHLc 0 3730 - 3 bge0 > 10.2.1.207 d0:d2:b0:0c:b9:41 UHLc 0 149944 - 3 bge0 > 10.2.1.208 38:89:2c:dd:5c:37 UHLc 0 179441 - 3 bge0 > 10.2.1.213 34:08:bc:be:3f:c6 UHLc 039991 - 3 bge0 > 10.2.1.217 4c:57:ca:08:33:c8 UHLc 0 6704 - 3 bge0 > 10.2.1.221 b0:c0:90:4b:8c:f8 UHLc 1 1299001 - 3 bge0 > 10.2.1.226 78:8a:20:d6:e7:b8 UHLc 0 3626 - 3 bge0 > 10.2.1.243 64:c7:53:aa:68:85 UHLc 0 3720 - 3 bge0 > 10.2.1.245 28:ff:3c:52:6a:51 UHLc 0 171234 - 3 bge0 > 10.2.2.1 00:16:41:ed:dd:47 UHLl 046132 - 1 bge0 > 10.2.2.1/3210.2.2.1 UCn00 - 4 bge0 > 10.2.2.21 ec:b1:d7:f3:09:a9 UHLc 1 252761 - 3 bge0 > 10.2.2.31 ac:1f:6b:96:38:96 UHLc 111629 - 3 bge0 > 10.2.2.61 9c:93:4e:5c:b7:9e UHLc 0 120968 - 3 bge0 > 10.2.2.62 9c:93:4e:2d:87:1f UHLc 0 3833 - 3 bge0 > 10.2.2.101 18:60:24:e3:eb:a1 UHLc 0 1872476 - 3 bge0 > 10.2.2.102 18:60:24:e3:f4:80 UHLc 0 5944221 - 3 bge0 > 10.2.2.103 18:60:24:e3:f3:99 UHLc 0 409286 - 3 bge0 > 10.2.2.104 18:60:24:e3:fb:97 UHLc 0 1452694 - 3 bge0 > 10.2.2.105 64:51:06:2b:ba:8b UHLc 0 559768 - 3 bge0 > 10.2.2.106 18:60:24:e3:f1:d2 UHLc 0 150568 - 3 bge0 > 10.2.2.107 64:51:06:2b:74:a3 UHLc 0 406897 - 3 bge0 > 10.2.2.108 18:60:24:e3:e0:63 UHLc 0 1759000 - 3 bge0 > 10.2.2.150 00:0b:82:c1:04:fb UHLc 020780 - 3 bge0 > 10.2.2.155 00:0b:82:d0:28:0c UHLc 0 3730 - 3 bge0 > 10.2.2.157 00:0b:82:d0:28:00 UHLc 0 3729 - 3 bge0 > 10.2.2.158 00:0b:82:d2:a9:aa UHLc 0 3729 - 3 bge0 > 10.2.2.255 link#1 UHLc 0 3671 - 3 bge0 > 10.2.4.1 00:16:41:ed:dd:47 UHLl 075492 - 1 bge0 > 10.2.4.1/3210.2.4.1 UCn00 - 4 bge0 > 10.2.4.101 6c:62:6d:93:1e:66 UHLc
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, 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: Current snapshot sets fail verification
It seems to have resolved itself. Maybe I just managed to run sysupgrade while the mirror was updating... On Thu, Jun 20, 2019 at 09:45:50PM +0200, Andreas Kusalananda Kähäri wrote: > > That's for amd64, sorry, forgot to mention. > > On Thu, Jun 20, 2019 at 09:44:54PM +0200, Andreas Kusalananda Kähäri wrote: > > With https://cdn.openbsd.org/pub/OpenBSD in /etc/installurl, sysupgrade > > currently fails: > > > > $ doas sysupgrade > > SHA256.sig 100% > > || > > 2141 00:00 > > Signature Verified > > Verifying old sets. > > base65.tgz 100% > > || > > 205 MB00:55 > > bsd 100% > > || > > 15658 KB00:05 > > bsd.mp 100% > > || > > 15752 KB00:02 > > bsd.rd 100% > > || > > 10022 KB00:01 > > comp65.tgz 100% > > || > > 73007 KB00:07 > > game65.tgz 100% > > || > > 2747 KB00:00 > > man65.tgz100% > > || > > 7391 KB00:01 > > xbase65.tgz 100% > > || > > 22580 KB00:02 > > xfont65.tgz 100% > > || > > 39342 KB00:04 > > Verifying sets. > > (SHA256) base65.tgz: FAILED > > (SHA256) bsd: FAILED > > (SHA256) bsd.mp: FAILED > > (SHA256) bsd.rd: FAILED > > (SHA256) comp65.tgz: FAILED > > (SHA256) game65.tgz: FAILED > > (SHA256) man65.tgz: FAILED > > (SHA256) xbase65.tgz: FAILED > > (SHA256) xfont65.tgz: FAILED > > > > -- > > Kusalananda > > Sweden > > -- > Kusalananda > Sweden -- Kusalananda Sweden
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: mandoc for report writing?
Hi Steve, Steve Litt wrote on Thu, Jun 20, 2019 at 02:31:38PM -0400: > On Thu, 20 Jun 2019 14:51:42 +0200 > Ingo Schwarze wrote: >> + Mandoc supports converting your paper to markdown format, >>just in case you want to publish in on github, too. > I've heard (and this could be BS) that once you get to Markdown format, > you can use Pandoc to convert that Markdown to pretty much any format > you want. I don't know how true that is, or what kind of compromises > you'd need to make with your control over output formatting. It is true that Pandoc can do lots of different conversions, though i never saw a need to use Pandoc or look at it. But one thing is sure: what you are proposing here is an absolutely terrible idea. Markdown is a piss-poor markup format. Very little expressive power, no support for semantic markup whatsoever, weak standardization (which makes it particularly vulnerable to poorly working conversions), exceptionally badly context dependent syntax (which also makes it unusually vulnerable to conversion errors). When you chain multiple conversions, the quality of the end result is necessarily less than the MINIMUM of the qualities of all intermediate formats and converters you travel trough (actually, even worse: the set of the markup features you can hope to preserve is a subset of the INTERSECTION of the feature sets of all intermediate languages and converters you use). So even if Pandoc were a good converter (which i don't know about), the end result is guaranteed to be terrible if you travel through markdown. Actually, the mandoc(1) manual page explicitly warns against using markdown as an intermediate format, even when targetting HTML, which is the one and only language that marksdown was developed to support - so you can expect even worse results for other target languages: Markdown Output [...] Markdown is a very weak markup language, so all semantic markup is lost, and even part of the presentational markup may be lost. Do not use this as an intermediate step in converting to HTML; instead, use -T html directly. Markdown output mode only makes sense if markdown is your desired final output format. Yours, Ingo
Re: Current snapshot sets fail verification
That's for amd64, sorry, forgot to mention. On Thu, Jun 20, 2019 at 09:44:54PM +0200, Andreas Kusalananda Kähäri wrote: > With https://cdn.openbsd.org/pub/OpenBSD in /etc/installurl, sysupgrade > currently fails: > > $ doas sysupgrade > SHA256.sig 100% > || > 2141 00:00 > Signature Verified > Verifying old sets. > base65.tgz 100% > || > 205 MB00:55 > bsd 100% > || > 15658 KB00:05 > bsd.mp 100% > || > 15752 KB00:02 > bsd.rd 100% > || > 10022 KB00:01 > comp65.tgz 100% > || > 73007 KB00:07 > game65.tgz 100% > || > 2747 KB00:00 > man65.tgz100% > || > 7391 KB00:01 > xbase65.tgz 100% > || > 22580 KB00:02 > xfont65.tgz 100% > || > 39342 KB00:04 > Verifying sets. > (SHA256) base65.tgz: FAILED > (SHA256) bsd: FAILED > (SHA256) bsd.mp: FAILED > (SHA256) bsd.rd: FAILED > (SHA256) comp65.tgz: FAILED > (SHA256) game65.tgz: FAILED > (SHA256) man65.tgz: FAILED > (SHA256) xbase65.tgz: FAILED > (SHA256) xfont65.tgz: FAILED > > -- > Kusalananda > Sweden -- Kusalananda Sweden
Current snapshot sets fail verification
With https://cdn.openbsd.org/pub/OpenBSD in /etc/installurl, sysupgrade currently fails: $ doas sysupgrade SHA256.sig 100% || 2141 00:00 Signature Verified Verifying old sets. base65.tgz 100% || 205 MB00:55 bsd 100% || 15658 KB00:05 bsd.mp 100% || 15752 KB00:02 bsd.rd 100% || 10022 KB00:01 comp65.tgz 100% || 73007 KB00:07 game65.tgz 100% || 2747 KB00:00 man65.tgz100% || 7391 KB00:01 xbase65.tgz 100% || 22580 KB00:02 xfont65.tgz 100% || 39342 KB00:04 Verifying sets. (SHA256) base65.tgz: FAILED (SHA256) bsd: FAILED (SHA256) bsd.mp: FAILED (SHA256) bsd.rd: FAILED (SHA256) comp65.tgz: FAILED (SHA256) game65.tgz: FAILED (SHA256) man65.tgz: FAILED (SHA256) xbase65.tgz: FAILED (SHA256) xfont65.tgz: FAILED -- Kusalananda Sweden
Re: network alias on different network
On Thu, Jun 20, 2019 at 07:05:57PM +, Victor Camacho wrote: > Hi, > > Using OpenBSD 6.4 and I wanted to run some alias ip addresses on one of the > interfaces. > My question is, can I use a different network as an alias? > > Example: > fw3# more hostname.bge0 > inet 10.2.0.1 255.255.0.0 > inet alias 10.2.1.1 255.255.255.255 > inet alias 10.2.2.1 255.255.255.255 > inet alias 10.2.4.1 255.255.255.255 > inet alias 10.2.6.1 255.255.255.255 > inet alias 172.17.11.1 255.255.255.255 > > I am having a problem pinging on the 172.17.11.0 network. > Ping 172.17.11.1 > Responds, but nothing else on the network. > I saw one thing on the internet that said 'alias' has to be on the same > network, but this was not specific as far as age and what operating system. > To me a router, routes. > Any clarification or better way to handle this would be appreciated. > You need to add the 172.17.11.1 with the correct netmask. The 255.255.255.255 netmask will not allow it to see any other system on that net. The 255.255.255.255 netmask should only be used for additional IPs that are already covered by an other IP address on that interface. Because of this outgoing traffic will use 10.2.0.1 as local IP address an not one of the other (10.2.1.1, 10.2.2.1, ...) unless explicitly bound. When using two different networks on the same interface just configure them the usual way (alias is just telling ifconfig not to replace the first IP address on the interface and instead add another one). > Here is the routing table (with public ip and mac addresses changed or > obscured): > > fw3# route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > defaultx.x.x.109 UGS 261 23105124 - 8 dc0 > 224/4 127.0.0.1 URS00 32768 8 lo0 > 10.2/1610.2.0.1 UCn 31 3623 - 4 bge0 > 10.2.0.1 00:16:41:ed:dd:47 UHLl 026952 - 1 bge0 > 10.2.1.1 00:16:41:ed:dd:47 UHLl 0 175419 - 1 bge0 > 10.2.1.1/3210.2.1.1 UCn00 - 4 bge0 > 10.2.1.11 b4:fb:e4:2c:5b:4d UHLc 0 249998 - 3 bge0 > 10.2.1.200 e8:36:17:6e:89:67 UHLc 0 3730 - 3 bge0 > 10.2.1.207 d0:d2:b0:0c:b9:41 UHLc 0 149944 - 3 bge0 > 10.2.1.208 38:89:2c:dd:5c:37 UHLc 0 179441 - 3 bge0 > 10.2.1.213 34:08:bc:be:3f:c6 UHLc 039991 - 3 bge0 > 10.2.1.217 4c:57:ca:08:33:c8 UHLc 0 6704 - 3 bge0 > 10.2.1.221 b0:c0:90:4b:8c:f8 UHLc 1 1299001 - 3 bge0 > 10.2.1.226 78:8a:20:d6:e7:b8 UHLc 0 3626 - 3 bge0 > 10.2.1.243 64:c7:53:aa:68:85 UHLc 0 3720 - 3 bge0 > 10.2.1.245 28:ff:3c:52:6a:51 UHLc 0 171234 - 3 bge0 > 10.2.2.1 00:16:41:ed:dd:47 UHLl 046132 - 1 bge0 > 10.2.2.1/3210.2.2.1 UCn00 - 4 bge0 > 10.2.2.21 ec:b1:d7:f3:09:a9 UHLc 1 252761 - 3 bge0 > 10.2.2.31 ac:1f:6b:96:38:96 UHLc 111629 - 3 bge0 > 10.2.2.61 9c:93:4e:5c:b7:9e UHLc 0 120968 - 3 bge0 > 10.2.2.62 9c:93:4e:2d:87:1f UHLc 0 3833 - 3 bge0 > 10.2.2.101 18:60:24:e3:eb:a1 UHLc 0 1872476 - 3 bge0 > 10.2.2.102 18:60:24:e3:f4:80 UHLc 0 5944221 - 3 bge0 > 10.2.2.103 18:60:24:e3:f3:99 UHLc 0 409286 - 3 bge0 > 10.2.2.104 18:60:24:e3:fb:97 UHLc 0 1452694 - 3 bge0 > 10.2.2.105 64:51:06:2b:ba:8b UHLc 0 559768 - 3 bge0 > 10.2.2.106 18:60:24:e3:f1:d2 UHLc 0 150568 - 3 bge0 > 10.2.2.107 64:51:06:2b:74:a3 UHLc 0 406897 - 3 bge0 > 10.2.2.108 18:60:24:e3:e0:63 UHLc 0 1759000 - 3 bge0 > 10.2.2.150 00:0b:82:c1:04:fb UHLc 020780 - 3 bge0 > 10.2.2.155 00:0b:82:d0:28:0c UHLc 0 3730 - 3 bge0 > 10.2.2.157 00:0b:82:d0:28:00 UHLc 0 3729 - 3 bge0 > 10.2.2.158 00:0b:82:d2:a9:aa UHLc 0 3729 - 3 bge0 > 10.2.2.255 link#1 UHLc 0 3671 - 3 bge0 > 10.2.4.1 00:16:41:ed:dd:47 UHLl 075492 - 1 bge0 > 10.2.4.1/3210.2.4.1 UCn00 - 4 bge0 > 10.2.4.101 6c:62:6d:93:1e:66 UHLc 1 2203177 - 3 bge0 > 10.2.4.102 c8:60:00:75:f3:d1 UHLc 015808 - 3 bge0 > 10.2.4.103 bc:ae:c5:e2:15:eb UHLc 095620 - 3 bge0 > 10.2.4.255 link#1 UHLc 0 3635 - 3 bge0 > 10.2.6.1 00:16:41:ed:dd:47
Re: mandoc for report writing?
On Thu, 20 Jun 2019 14:51:42 +0200 Ingo Schwarze wrote: > Hi Paul, > > Paul Swanson wrote on Wed, Jun 19, 2019 at 07:09:39PM +: > > > Has anyone had any experience with using mandoc for report > > writing? > > I doubt that. > > > I realise it may be a silly / naive question. > > > > But in recent times I've started using groff (with grefer) to write > > academic papers, because it's relatively easy to use for my > > purposes. > > Groff is no doubt an excellent tool for that task. > Not a big surprise either because Jerry Saltzer originally > implemented RUNOFF in 1964 to typeset his thesis - and this > family of systems has been used again and again for similar > purposes during these 5 1/2 decades. > > > As such, it got me wondering if mandoc is suitable for such a > > purpose. Coincidentally, the past few days I've been researching Asciidoctor and pandoc for writing my books in both ePub and PDF format. [snip] > > + Mandoc supports converting your paper to markdown format, >just in case you want to publish in on github, too. I've heard (and this could be BS) that once you get to Markdown format, you can use Pandoc to convert that Markdown to pretty much any format you want. I don't know how true that is, or what kind of compromises you'd need to make with your control over output formatting. The OP is doing academic papers, which presumably need go only to PDF format. In that case, LaTeX, LyX, conTeXt are great choices. SteveT Steve Litt June 2019 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
network alias on different network
Hi, Using OpenBSD 6.4 and I wanted to run some alias ip addresses on one of the interfaces. My question is, can I use a different network as an alias? Example: fw3# more hostname.bge0 inet 10.2.0.1 255.255.0.0 inet alias 10.2.1.1 255.255.255.255 inet alias 10.2.2.1 255.255.255.255 inet alias 10.2.4.1 255.255.255.255 inet alias 10.2.6.1 255.255.255.255 inet alias 172.17.11.1 255.255.255.255 I am having a problem pinging on the 172.17.11.0 network. Ping 172.17.11.1 Responds, but nothing else on the network. I saw one thing on the internet that said 'alias' has to be on the same network, but this was not specific as far as age and what operating system. To me a router, routes. Any clarification or better way to handle this would be appreciated. Thanks in advance, Victor Here is the routing table (with public ip and mac addresses changed or obscured): fw3# route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultx.x.x.109 UGS 261 23105124 - 8 dc0 224/4 127.0.0.1 URS00 32768 8 lo0 10.2/1610.2.0.1 UCn 31 3623 - 4 bge0 10.2.0.1 00:16:41:ed:dd:47 UHLl 026952 - 1 bge0 10.2.1.1 00:16:41:ed:dd:47 UHLl 0 175419 - 1 bge0 10.2.1.1/3210.2.1.1 UCn00 - 4 bge0 10.2.1.11 b4:fb:e4:2c:5b:4d UHLc 0 249998 - 3 bge0 10.2.1.200 e8:36:17:6e:89:67 UHLc 0 3730 - 3 bge0 10.2.1.207 d0:d2:b0:0c:b9:41 UHLc 0 149944 - 3 bge0 10.2.1.208 38:89:2c:dd:5c:37 UHLc 0 179441 - 3 bge0 10.2.1.213 34:08:bc:be:3f:c6 UHLc 039991 - 3 bge0 10.2.1.217 4c:57:ca:08:33:c8 UHLc 0 6704 - 3 bge0 10.2.1.221 b0:c0:90:4b:8c:f8 UHLc 1 1299001 - 3 bge0 10.2.1.226 78:8a:20:d6:e7:b8 UHLc 0 3626 - 3 bge0 10.2.1.243 64:c7:53:aa:68:85 UHLc 0 3720 - 3 bge0 10.2.1.245 28:ff:3c:52:6a:51 UHLc 0 171234 - 3 bge0 10.2.2.1 00:16:41:ed:dd:47 UHLl 046132 - 1 bge0 10.2.2.1/3210.2.2.1 UCn00 - 4 bge0 10.2.2.21 ec:b1:d7:f3:09:a9 UHLc 1 252761 - 3 bge0 10.2.2.31 ac:1f:6b:96:38:96 UHLc 111629 - 3 bge0 10.2.2.61 9c:93:4e:5c:b7:9e UHLc 0 120968 - 3 bge0 10.2.2.62 9c:93:4e:2d:87:1f UHLc 0 3833 - 3 bge0 10.2.2.101 18:60:24:e3:eb:a1 UHLc 0 1872476 - 3 bge0 10.2.2.102 18:60:24:e3:f4:80 UHLc 0 5944221 - 3 bge0 10.2.2.103 18:60:24:e3:f3:99 UHLc 0 409286 - 3 bge0 10.2.2.104 18:60:24:e3:fb:97 UHLc 0 1452694 - 3 bge0 10.2.2.105 64:51:06:2b:ba:8b UHLc 0 559768 - 3 bge0 10.2.2.106 18:60:24:e3:f1:d2 UHLc 0 150568 - 3 bge0 10.2.2.107 64:51:06:2b:74:a3 UHLc 0 406897 - 3 bge0 10.2.2.108 18:60:24:e3:e0:63 UHLc 0 1759000 - 3 bge0 10.2.2.150 00:0b:82:c1:04:fb UHLc 020780 - 3 bge0 10.2.2.155 00:0b:82:d0:28:0c UHLc 0 3730 - 3 bge0 10.2.2.157 00:0b:82:d0:28:00 UHLc 0 3729 - 3 bge0 10.2.2.158 00:0b:82:d2:a9:aa UHLc 0 3729 - 3 bge0 10.2.2.255 link#1 UHLc 0 3671 - 3 bge0 10.2.4.1 00:16:41:ed:dd:47 UHLl 075492 - 1 bge0 10.2.4.1/3210.2.4.1 UCn00 - 4 bge0 10.2.4.101 6c:62:6d:93:1e:66 UHLc 1 2203177 - 3 bge0 10.2.4.102 c8:60:00:75:f3:d1 UHLc 015808 - 3 bge0 10.2.4.103 bc:ae:c5:e2:15:eb UHLc 095620 - 3 bge0 10.2.4.255 link#1 UHLc 0 3635 - 3 bge0 10.2.6.1 00:16:41:ed:dd:47 UHLl 00 - 1 bge0 10.2.6.1/3210.2.6.1 UCn00 - 4 bge0 10.2.255.255 10.2.0.1 UHb0 1288 - 1 bge0 x.x.x.108/28 x.x.x.113 UCn2 362071 - 4 dc0 x.x.x.109 54:39:69:1f:23:7c UHLch 1 190137 - 3 dc0 x.x.x.110 00:22:55:69:24:59 UHLc 1 361719 - 3 dc0 x.x.x.113 00:24:e2:3f:ac:54 UHLl 0 195942 - 1 dc0 x.x.x.123 x.x.x.113 UHb00 - 1 dc0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 2 149 32768 1 lo0 172.17.11.100:16:41:ed:dd:47 UHLl 0 1116 - 1 bge0 172.17.11.1/32
Re: mandoc for report writing?
Hi Paul, Paul Swanson wrote on Wed, Jun 19, 2019 at 07:09:39PM +: > Has anyone had any experience with using mandoc for report writing? I doubt that. > I realise it may be a silly / naive question. > > But in recent times I've started using groff (with grefer) to write > academic papers, because it's relatively easy to use for my purposes. Groff is no doubt an excellent tool for that task. Not a big surprise either because Jerry Saltzer originally implemented RUNOFF in 1964 to typeset his thesis - and this family of systems has been used again and again for similar purposes during these 5 1/2 decades. > As such, it got me wondering if mandoc is suitable for such a purpose. Mandoc provides a subset of the functionality of groff plus some additional functionality. No doubt the subset has grown during the decade that mandoc is now in production. But i'd still say the majority of groff typesetting and report writing functionality of groff is not provided by mandoc: - The document format is strictly fixed to "one manual page". You cannot have a title, you cannot have a subtitle, you cannot mention the author(s) and their institution and location at the beginning (only at the end), you cannot have an abstract, you cannot have footnotes, you cannot have images or drawings, you cannot have appendices or indexes, a table of contents only appears in HTML output but not in PDF output, sections always start in the same order: NAME, SYNTAX, DESCRIPTION ... - For an academic paper, typographic output quality is quite important. Mandoc PDF output quality is so much worse than groff PDF output quality that it is probably insufficient for an academic paper and no doubt makes you look sloppy and unprofessional. - You have no control over presentation format. First level titles are always flush left and ALL CAPS, second level title are always slightly indented and bold, there is no way to have third level titles or section numbering, running text is always indented. You get no paragraph adjustment and no hyphenation. Fonts are hardcoded, there are no ligatures, kerning is so simplistic that you could almost call it unsupported. - You cannot use refer(1) or pic(1) or chem(1) or any other add-on macro set with the exception of tbl(7) and eqn(7) - and typographical output quality of tbl(7) and eqn(7) in PDF output is abysmal. On the other hand, the bonus features mandoc provides over groff are irrelevant for your purpose: + Mandoc supports seamless display of your paper by man(1) at the command line, and your paper can be found by system apropos(1). + Mandoc supports converting your paper to man(7) format, just in case your want to support installing it on, say, SUN Solaris 9 machines. + Mandoc supports converting your paper to markdown format, just in case you want to publish in on github, too. + In case your paper is explaining a library function or programming utility, HTML output from mandoc will be semantic, while groff will strip it to presentational HTML of much lower quality - but the semantic macros that mdoc(7) provides might be of little relevance for the subject area you want to write about. + Mandoc helps you check whether the formatting details of your paper adhere to the conventions of OpenBSD (or at your choice, NetBSD) base system manual pages - but not the conventions required by whatever scientific journal you may be targetting. You may be able to use a hammer to split a plank of wood in the middle, but it will be tedious work and the result won't look pretty. For an academic paper, use groff, Heirloom troff (also in the ports tree), or LaTeX (also in the ports tree). Neither the mdoc(7) nor the man(7) macros are adequate. Nowadays, you would probably want to look at the groff_mom(7) macro set. If you feel extremely conservative, you might stick to the groff_mm(7) or groff_ms(7) macro sets, but even that would no longer seem a natural choice. Yours, Ingo
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
