dhclient exiting on lease expiry
Hi, I have been upgrading my machines to 5.3 this weekend and I am seeing some strange behaviours with dhclient. The config is simple: /etc/dhclient.conf send host-name pc-1; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; (FWIW The dhcp server serves up constant IP addresses based on the MAC) There is only one i/f with the wrinkle that I am temporarily running an inet alias off the i/f as well: /etc/hostname.re0 dhcp NONE NONE NONE NONE inet alias 192.168.67.24 255.255.255.0 NONE Up to the upgrade this was ticking along with no problems. Now, whenever the lease expires the dhclient daemon exits taking the inet alias with it, and I have no connectivity. I can restart dhclient but this leaves the inet alias dead. /var/log/daemon shows the following (*): May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) ... May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting However if I force a renewal with pkill -HUP dhclient I see this: May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 -- renewal in 43200 seconds. So it looks like an issue when the lease times out. There was nothing in the upgrade notes, and a search through the lists on marc.info only brings up to release note improvements, nothing about any configuration changes that may be needed. (*) For full context I have avahi-daemon installed so the full daemon log for the time the lease expired is as follows: May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.24 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.24. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface re0.IPv4 for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address record for 192.168.67.40 on re0.IPv4. May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid Let the beatings with the clue bat begin. -- Mike
Re: Re : Tux cups
Sun 12.May'13 at 15:41:11 -0600, Evan Root So Stuart, I was looking at the OpenBSD mailing list rules because I wasn't sure about long links and I saw that lines over 72 characters are discouraged, that's were I decided to manually put in line breaks. :/ Although your point about a direct link to something that isn't google is a valid point. Question for everybody that uses console mailers; Does Mutt and the other text based mailers have line wrap enabled by default? or do they go off the edge mutt and console MUA's usually use an external editor, $VISUAL, usually vi(1). The text will just continue to the width of you terminal and then wrap the line on to the next row. Vim, can automatically be set to wrap lines i believe, i don't use it though, I just use the base vi(1) and then fmt(1) to format the text. Same for mail(1) if use the command to write in an external editor. So, the answer is no - the mutt and console MUA's don't do text formatting; the editor does.
Re: USB temperature sensors
On 2013-05-10, Christian Weisgerber na...@mips.inka.de wrote: Stuart Henderson s...@spacehopper.org wrote: TemperNTC (http://www.pcsensor.com/index.php?_a=productproduct_id=7) uses uthum(4) but has a problem where the sensor drops out occasionally; diff I posted to tech@ improves (but doesn't totally fix) this. This seems specific to TemperNTC, I don't have any other uthum(4) devices myself but it seems e.g. TemperHUM is more reliable. My TEMPerHUM also drops out occasionally. As far as the readings are concerned, the temperature it reports is consistently some 1.5 .. 2.0 degC higher than what an alcohol thermometer in the same room shows, i.e., the measurements are reproducible if somewhat miscalibrated. I doubt that the humidity readings are any good, but I haven't checked. I've just got a ugold to play with locally (rather than my other one which is in a remote server room), all three of these are in pretty much the same location next to my laptop: hw.sensors.ugold1.temp0=22.75 degC (inner) hw.sensors.uthum1.temp0=19.00 degC (inner) hw.sensors.uthum1.temp1=22.99 degC (outer/ntc) I don't have an alcohol/Hg thermometer to compare with though. Maybe I'll try the NTC in a cup of iced water to see how that looks (the ugold and uthum's inner sensors are somewhat harder to check in that way :)
Re: NPPPD with intermediate LTS
YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: In this case, npppd assumes the LAC is using Proxy LCP and Authentication AVP in RFC 2661. Is it possible to force npppd to treat it as a non-dialin tunnel? 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about proxy LCP and authentication, I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? --yasuoka Thanks, Joe
Re: dhclient exiting on lease expiry
On Mon, May 13, 2013 at 09:40:59AM +0100, Mike Williams wrote: Hi, I have been upgrading my machines to 5.3 this weekend and I am seeing some strange behaviours with dhclient. The config is simple: /etc/dhclient.conf send host-name pc-1; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; (FWIW The dhcp server serves up constant IP addresses based on the MAC) There is only one i/f with the wrinkle that I am temporarily running an inet alias off the i/f as well: /etc/hostname.re0 dhcp NONE NONE NONE NONE inet alias 192.168.67.24 255.255.255.0 NONE Upgraded from what version? Yes, the 5.3 dhclient will remove all aliases as part of taking control of the interface. So a renewal will remove the interface. In fact adding the alias should either cause dhclient to exit, or the alias will be removed when the lease is obtained. This behaviour was mentioned in the release notes: all existing addresses on the interface are deleted when binding a new lease. Up to the upgrade this was ticking along with no problems. Now, whenever the lease expires the dhclient daemon exits taking the inet alias with it, and I have no connectivity. I can restart dhclient but this leaves the inet alias dead. /var/log/daemon shows the following (*): May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) ... May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting Now that is an unfortunate and insufficiently useful error message. However if I force a renewal with pkill -HUP dhclient I see this: May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 -- renewal in 43200 seconds. And that does NOT remove the alias? That would be contrary to my expectation. So it looks like an issue when the lease times out. There was nothing in the upgrade notes, and a search through the lists on marc.info only brings up to release note improvements, nothing about any configuration changes that may be needed. (*) For full context I have avahi-daemon installed so the full daemon log for the time the lease expired is as follows: May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.24 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.24. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface re0.IPv4 for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address record for 192.168.67.40 on re0.IPv4. May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid Let the beatings with the clue bat begin. -- Mike Not sure what Avahi is doing. :-) If you capture the output from 'route monitor', you can see what RTM_NEWADDR, RTM_DELADDR, etc. messages are flying around that dhclient will be paying attention to. Bottom line: alias and dhclient do not play well together. They never have in a general sense, and 5.3 tightens things up significantly. We are looking at making them work together safely and reliably. Ken
Re: dhclient exiting on lease expiry
On 05/13/13 15:19, Kenneth R Westerback wrote: On Mon, May 13, 2013 at 09:40:59AM +0100, Mike Williams wrote: Hi, I have been upgrading my machines to 5.3 this weekend and I am seeing some strange behaviours with dhclient. The config is simple: /etc/dhclient.conf send host-name pc-1; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; (FWIW The dhcp server serves up constant IP addresses based on the MAC) There is only one i/f with the wrinkle that I am temporarily running an inet alias off the i/f as well: /etc/hostname.re0 dhcp NONE NONE NONE NONE inet alias 192.168.67.24 255.255.255.0 NONE Upgraded from what version? 5.2 release. Yes, the 5.3 dhclient will remove all aliases as part of taking control of the interface. So a renewal will remove the interface. In fact adding the alias should either cause dhclient to exit, or the alias will be removed when the lease is obtained. This behaviour was mentioned in the release notes: all existing addresses on the interface are deleted when binding a new lease. Ok, I can live with that, time to sort out the temporariness (sp?) of the alias. Up to the upgrade this was ticking along with no problems. Now, whenever the lease expires the dhclient daemon exits taking the inet alias with it, and I have no connectivity. I can restart dhclient but this leaves the inet alias dead. /var/log/daemon shows the following (*): May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) ... May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting Now that is an unfortunate and insufficiently useful error message. I feel a new tagline in the offing ;-) However if I force a renewal with pkill -HUP dhclient I see this: May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 -- renewal in 43200 seconds. And that does NOT remove the alias? That would be contrary to my expectation. No, it does remove the alias as well. I was comparing the behaviour of a forced renewal to lease expiry on the dhclient daemon. So it looks like an issue when the lease times out. There was nothing in the upgrade notes, and a search through the lists on marc.info only brings up to release note improvements, nothing about any configuration changes that may be needed. (*) For full context I have avahi-daemon installed so the full daemon log for the time the lease expired is as follows: May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to 192.168.67.2 port 67 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 (00:40:63:dd:9f:c0) May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.24 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.24. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface re0.IPv4 for mDNS. May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address record for 192.168.67.40 on re0.IPv4. May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not 192.168.67.40, deleted from re0; exiting May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record for 192.168.67.40 on re0. May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast group on interface re0.IPv4 with address 192.168.67.40. May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: Can't assign requested address May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no longer relevant for mDNS. May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid Let the beatings with the clue bat begin. -- Mike Not sure what Avahi is doing. :-) If you capture the output from 'route monitor', you can see what RTM_NEWADDR, RTM_DELADDR, etc. messages are flying around that dhclient will be paying attention to. Me neither, but there is a functional link and avahi does seem to be acting in relation to dhclient behaviour. I provided the context if anyone had a light-bulb moment because of it. I'll report what route monitor reports when the lease next expires. Bottom line: alias and dhclient do not play well together. They never have in a general sense, and 5.3 tightens things up significantly. We are looking at making them work together safely and reliably. Nice to hear, I'll sort myself out re aliases. -- Mike
Re: Claws-mail frequently dumps core on 5.3R
On Fri, 10 May 2013 14:42:48 -0700 Philip Guenther guent...@gmail.com wrote: The quality of the error checking demonstrated by this crash, btw, should have you filing bugs with the claws-mail developers. Bad input files is not a valid reason to crash; it should be reporting what file is involved and the most precise error message it has for the problem and existing with a non-zero status. Thanks alot for your help. I will report this issue to the claws project. Meanwhile I stick to Sylpheed, which does not have this bug, apparently. Thanks, Erwin
remote management
Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Thanks Tony
who is using obsd
on his/her laptop as *only* OS and uses it daily for scientific work? please contact me off list. Thanks
Re: who is using obsd
PS: scientific: physics, math, bio, etc...
Re: remote management
On 05/13/2013 03:24 PM, Tony Berth wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Oh, I remember those. Last IP KVM switch I used worked BETTER for OpenBSD than it did for Windows... Seriously. Windows desktop was a garbled mess, looked like a badly tuned TV set (for those that remember when you could and needed to tune TVs), but running OpenBSD with X, it Just Worked. Go figure. Getting the client software to run was another matter all together, as I recall, it was a horribly Windows/IE dependent. Really, though. If it's in a data center, usually I just use the remote access controller on most servers these days or a serial console. Just remember... if you got a big *** lock on the data center door (you should), make sure your remote console (however you do it) is comparably secure. Putting your remote access on the same network as all your users is similar to removing the locks on the data center door. Not changing the default RAC password and/or IDs is like putting a Welcome mat under the (unlocked) door of the data center. And ask yourself...why do you run OpenBSD? Maybe because of the security. What OS do you think is at the base of your IP KVM? Probably not OpenBSD. Strength of a chain is the weakest link and all that -- if someone can knock over your KVM, they own your box. Don't compromise your machine with a bad remote console. Nick.
Re: who is using obsd
OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. On 05/13/2013 05:12 PM, Pau wrote: on his/her laptop as *only* OS and uses it daily for scientific work? please contact me off list. Thanks -- Salim A. Shaw System Administrator OpenBSD CentOS / Free Software Advocate Need stability and security -- Try OpenBSD. BSD,ISC license all the way: Sell services, don't lease secrets
Re: who is using obsd
Salim Shaw [salims...@vfemail.net] wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. Salim, that's quite strange. OpenBSD has worked on my Sun 4/110 desktop since 1995. And more recently, I've been using it on i386 and later even amd64 machines, as a desktop environment! It could just be some kind of hallucination. You know, I had this one dream of being tied up and injected with sodium pentothal...
Re: who is using obsd
2013/5/13 Chris Cappuccio ch...@nmedia.net Salim Shaw [salims...@vfemail.net] wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. Salim, that's quite strange. OpenBSD has worked on my Sun 4/110 desktop since 1995. And more recently, I've been using it on i386 and later even amd64 machines, as a desktop environment! It could just be some kind of hallucination. You know, I had this one dream of being tied up and injected with sodium pentothal... +1
Re: remote management
thanks for the prompt replies. Any recommendation for IPMI cards and KVM over IP switches that work well with openbsd? Tony On Tue, May 14, 2013 at 12:07 AM, Nick Holland n...@holland-consulting.netwrote: On 05/13/2013 03:24 PM, Tony Berth wrote: Dear Group, I would like to know what kind of environment you use for remote management of one or more openbsd servers. Which KVM over IP solution would you recomend. Oh, I remember those. Last IP KVM switch I used worked BETTER for OpenBSD than it did for Windows... Seriously. Windows desktop was a garbled mess, looked like a badly tuned TV set (for those that remember when you could and needed to tune TVs), but running OpenBSD with X, it Just Worked. Go figure. Getting the client software to run was another matter all together, as I recall, it was a horribly Windows/IE dependent. Really, though. If it's in a data center, usually I just use the remote access controller on most servers these days or a serial console. Just remember... if you got a big *** lock on the data center door (you should), make sure your remote console (however you do it) is comparably secure. Putting your remote access on the same network as all your users is similar to removing the locks on the data center door. Not changing the default RAC password and/or IDs is like putting a Welcome mat under the (unlocked) door of the data center. And ask yourself...why do you run OpenBSD? Maybe because of the security. What OS do you think is at the base of your IP KVM? Probably not OpenBSD. Strength of a chain is the weakest link and all that -- if someone can knock over your KVM, they own your box. Don't compromise your machine with a bad remote console. Nick.
Re: who is using obsd
On May 13, 2013 4:33 PM, Chris Cappuccio ch...@nmedia.net wrote: Salim Shaw [salims...@vfemail.net] wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. Salim, that's quite strange. OpenBSD has worked on my Sun 4/110 desktop since 1995. ... It could just be some kind of hallucination. ROFL! The myth that there an OS can only be a server or a desktop OS still seems to be out there.
Re: who is using obsd
On 05/13/13 17:28, Salim Shaw wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. You're quite a comedian. However, don't give up your day job. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: who is using obsd
You are wrong with your statement that OpenBSD is not designed for the desktop. We are running several hundred desktop on the enterprise, thin clients and so on ... On Mon, 2013-05-13 at 17:28 -0400, Salim Shaw wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. On 05/13/2013 05:12 PM, Pau wrote: on his/her laptop as *only* OS and uses it daily for scientific work? please contact me off list. Thanks -- Reiner Jung r.j...@mtier.org
Re: who is using obsd
Flame bait. Not even funny. Salim Shaw salims...@vfemail.net wrote: OpenBSD is a server/router/network service OS, it's not designed for desktops. OpenBSD is the pre-eminent platform for Firewalling, IPsec, IPv6. Trying to shove OpenBSD onto the desktop is the ultimate case of square peg/round hole. On 05/13/2013 05:12 PM, Pau wrote: on his/her laptop as *only* OS and uses it daily for scientific work? please contact me off list. Thanks
Re: Re : Tux cups
On Mon, May 13, 2013 at 11:58:08AM +0100, James Griffin wrote: I just use the base vi(1) and then fmt(1) to format the text. Same for mail(1) if use the command to write in an external editor. Why not: set editor=EXINIT=':set wrapmargin=8' vi %s in the muttrc? No need for fmt. -- Brett Lymn Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer.
Is fdisk, disklabel and newfs enough to reset an SSD
I would like to reinstall a fresh system on an SSD that contains an existing installation. From my limited knowledge of SSDs, I wonder if the drive controller may retain data from the old filesystem, unaware that there is a new filesystem put in place. Is this a concern? If so, how does one reset a used SSD for optimal operation with a fresh install?
xenocara build failure
This is probably something stupid I'm doing, but I can't see it right this second. Trying to build xenocara from sources pulled from anon...@anoncvs3.usa.openbsd.org:/cvs as of about 60 minutes before sending this email message gives me cc -O2 -pipe -I/usr/xenocara/lib/freetype/include -I/usr/xenocara/lib/freetype/builds/unix -I/usr/xenocara/lib/freetype/src/lzw -DFT2_BUILD_LIBRARY -c /usr/xenocara/lib/freetype/src/type1/type1.c -o type1.o In file included from /usr/xenocara/lib/freetype/src/type1/type1.c:23: /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 'parse_private': /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: 'T1_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: (Each undeclared identifier is reported only once /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: for each function it appears in.) In file included from /usr/xenocara/lib/freetype/src/type1/type1.c:23: /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 'parse_dict': /usr/xenocara/lib/freetype/src/type1/t1load.c:1871: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1871: error: 'T1_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1872: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1873: error: 'T1_FONTDIR_AFTER_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1978: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1990: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 't1_init_loader': /usr/xenocara/lib/freetype/src/type1/t1load.c:2047: error: 'struct T1_Loader_' has no member named 'keywords_encountered' *** Error 1 in lib/freetype (bsd.lib.mk:37 'type1.o': @cc -O2 -pipe -I/usr/xenocara/lib/freetype/include -I/usr/xenocara/lib/freetype/...) *** Error 1 in lib/freetype (Makefile:36 'build') *** Error 1 in lib (bsd.subdir.mk:48 'build') *** Error 1 in . (bsd.subdir.mk:48 'realbuild') *** Error 1 in /usr/xenocara (Makefile:35 'build') Any hints as to what I'm doing wrong?
Re: Is fdisk, disklabel and newfs enough to reset an SSD
On 05/14/13 00:04, Clint Pachl wrote: I would like to reinstall a fresh system on an SSD that contains an existing installation. From my limited knowledge of SSDs, I wonder if the drive controller may retain data from the old filesystem, unaware that there is a new filesystem put in place. Is this a concern? If so, how does one reset a used SSD for optimal operation with a fresh install? I've done a fresh install of OpenBSD over top of OpenBSD (and other OSes) many times across many SSDs and I've never had a problem. But I'm not entirely sure what you mean... 1) Do you mean your new installation will see files left over from a previous install? No, it won't. 2) Do you mean there could still be data residing on unused parts of the SSD? Yes, it can happen. SSDs have their own way of wear-leveling. What the filesystem considers to be cylinder X, head Y and sector Z will probably not be the same *physical* cells on the SSD twice in a row. That's not a function of the OS, but the SSD itself. Do a little googling and you'll see what I mean: There's no guaranteed way to erase an SSD. I've read stories of people that have had SSDs crap out on them and instead of sending them back to the manufacturer for warranty repair/replacement, they just chuck them out and buy new ones. Why? Because there's no way to guarantee your private data has actually been erased. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: xenocara build failure
On 05/14/13 00:15, Marco S Hyman wrote: This is probably something stupid I'm doing, but I can't see it right this second. Trying to build xenocara from sources pulled from anon...@anoncvs3.usa.openbsd.org:/cvs as of about 60 minutes before sending this email message gives me cc -O2 -pipe -I/usr/xenocara/lib/freetype/include -I/usr/xenocara/lib/freetype/builds/unix -I/usr/xenocara/lib/freetype/src/lzw -DFT2_BUILD_LIBRARY -c /usr/xenocara/lib/freetype/src/type1/type1.c -o type1.o In file included from /usr/xenocara/lib/freetype/src/type1/type1.c:23: /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 'parse_private': /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: 'T1_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: (Each undeclared identifier is reported only once /usr/xenocara/lib/freetype/src/type1/t1load.c:1037: error: for each function it appears in.) In file included from /usr/xenocara/lib/freetype/src/type1/type1.c:23: /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 'parse_dict': /usr/xenocara/lib/freetype/src/type1/t1load.c:1871: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1871: error: 'T1_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1872: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1873: error: 'T1_FONTDIR_AFTER_PRIVATE' undeclared (first use in this function) /usr/xenocara/lib/freetype/src/type1/t1load.c:1978: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c:1990: error: 'struct T1_Loader_' has no member named 'keywords_encountered' /usr/xenocara/lib/freetype/src/type1/t1load.c: In function 't1_init_loader': /usr/xenocara/lib/freetype/src/type1/t1load.c:2047: error: 'struct T1_Loader_' has no member named 'keywords_encountered' *** Error 1 in lib/freetype (bsd.lib.mk:37 'type1.o': @cc -O2 -pipe -I/usr/xenocara/lib/freetype/include -I/usr/xenocara/lib/freetype/...) *** Error 1 in lib/freetype (Makefile:36 'build') *** Error 1 in lib (bsd.subdir.mk:48 'build') *** Error 1 in . (bsd.subdir.mk:48 'realbuild') *** Error 1 in /usr/xenocara (Makefile:35 'build') Any hints as to what I'm doing wrong? I've seen this before. After you rebuild your system, reboot. (Yes, in addition to after rebooting into the new kernel.) Bet your problem will be solved. -- Scott McEachern https://www.blackstaff.ca Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
Re: xenocara build failure
On May 13, 2013, at 9:47 PM, Scott McEachern sc...@blackstaff.ca wrote: *** Error 1 in lib/freetype (bsd.lib.mk:37 'type1.o': @cc -O2 -pipe -I/usr/xenocara/lib/freetype/include -I/usr/xenocara/lib/freetype/...) *** Error 1 in lib/freetype (Makefile:36 'build') *** Error 1 in lib (bsd.subdir.mk:48 'build') *** Error 1 in . (bsd.subdir.mk:48 'realbuild') *** Error 1 in /usr/xenocara (Makefile:35 'build') Any hints as to what I'm doing wrong? I've seen this before. After you rebuild your system, reboot. (Yes, in addition to after rebooting into the new kernel.) Bet your problem will be solved. Tried that... still fails in the same place. I think I'll try grabbing source from a different CVS server and see if that makes a difference... grasping at straws.
Re: Is fdisk, disklabel and newfs enough to reset an SSD
On Mon, May 13, 2013 at 21:04, Clint Pachl wrote: I would like to reinstall a fresh system on an SSD that contains an existing installation. From my limited knowledge of SSDs, I wonder if the drive controller may retain data from the old filesystem, unaware that there is a new filesystem put in place. Is this a concern? If so, how does one reset a used SSD for optimal operation with a fresh install? 'atactl drive secerase' will tell the drive the old contents are no longer needed. None of the other tools currently do that. I don't think it's a concern.
Re: Is fdisk, disklabel and newfs enough to reset an SSD
Scott McEachern wrote: 2) Do you mean there could still be data residing on unused parts of the SSD? Yes, it can happen. Yes, this is what I'm referring to. I was hoping there was some way to instruct the drive controller that the entire drive space is free? SSDs have their own way of wear-leveling. What the filesystem considers to be cylinder X, head Y and sector Z will probably not be the same *physical* cells on the SSD twice in a row. That's not a function of the OS, but the SSD itself. I understand. That's why I'm concerned about #2 above. Would dd'ing to the drive all 1s then all 0s be effective? I see Intel has an SSD Toolbox that does secure erase. It requires windows so I am unable to check it out. www.intel.com/go/ssdtoolbox I wonder what this utility does to achieve secure erase? Can we replicate its functionality with standard Unix tools?
