Upgrade procedure (6.4 -> 6.5)
Hi, I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see that /etc/networks and some other files (like malloc.conf.5) are still present, although there is no use for them in the new release. Is there a reason why these files are not listed in "FIles to remove"? Is there a way to track them? It's not like something gonna break, but old configuration files (and manual pages) lying around can make someone's life harder during the debug session.
Re: Upgrade procedure (6.4 -> 6.5)
Am 02.05.2019 um 09:52 schrieb Consus: > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > that /etc/networks and some other files (like malloc.conf.5) are still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to remove"? > Is there a way to track them? It's not like something gonna break, but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. Take a look at the sysutils/sysclean port. Regards Markus
Re: 6.5 auto_install fails due to custom /var/tmp?
On Tue, 30 Apr 2019 13:29:47 -0700 Lyndon Nerenberg wrote: > > But I should be able to accomplish what I need using rc.firsttime > > and a tiny bit of hackery. > > Sadly, no :-( How about partition as /var/temp/ & autoinstall Lyndon? Then in rc.firsttime:- *) umount /var/temp/ *) check /var/tmp is a symlink && *) rm it *) mv /var/temp /var/tmp *) chmod/own /var/tmp as req'd *) mount /var/tmp Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: User who invoke doas
On 5/1/19 10:28 PM, Adam Steen wrote: > Hi > > In a shell script invoked by doas, is it possible to find which user > invoke the script? my search a the moment has come up empty. most likely place would be an environment variable, right? So ... $ whoami nick $ doas -s # whoami root # env |grep nick LOGNAME=nick HOME=/home/nick MAIL=/var/mail/nick PATH=/home/nick/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. USER=nick # echo "I started out as $LOGNAME" I started out as nick 'dar ya go. Nick.
Got hits Job offering in the mail
Got approached by a head hunter. If anyone in the community is interested and read it as is, I am just copy pasting, and I know NOTHING about this job or the head hunter that sent me the bellow email: Hii There! Greetings of the day!! I found your resume from one of the job portal and just want to check if you are available for new opportunity and it seems really a good match with the requirement so please have a look at the requirement and let me know if you are comfortable with the requirement. If interested please revert back with updated resume *JD : OpenBSD Resource* *Start Date: Immediate* *Location: Apple Park* *Tasks:* 1. Document the existing state of projects - Diff versions in macOS vs released by project - Public state of projects (how much active development, direction, potential replacements, license status, etc.) 2. Bring macOS forward - Pull latest project versions in - Review radars to determine what is fixed in latests versions vs. is still a problem or is a new feature/enhancement request - Fix high/medium impact issues - Upstream changes, if possible and as appropriate 3. Testing suite - Integrate existing open source tests - Develop new tests where there are gaps 4. Automate the process - Create a tool that will automate as much of the work as possible - Pull down latest repo, apply Apple-specific patches, prep for submission to build - Would be run on a set cadence relative to OS releases 5. GPL replacements - Develop BSD licensed replacements for any strategically important projects that don’t currently have one Thanks & Regards, *Jack Thomson* *Talent Acquisition Team* *Ph: 732-200-1396* *2 N. Market St., #400, San Jose, CA, 95113* *jac...@e-solutionsinc.com* www.e-solutionsinc.com
Re: Upgrade procedure (6.4 -> 6.5)
On 5/2/19 1:52 AM, Consus wrote: > Hi, > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > that /etc/networks and some other files (like malloc.conf.5) are still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to remove"? > Is there a way to track them? It's not like something gonna break, but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. There is no promise that an upgraded machine will be file-for-file identical to a fresh install. Here is the list of problems this might cause you, as you can see, it's a long list and quite horrible: * If you use the same hw for 20 years, you might run out of disk space? Ok, not very long and not very horrible. You are trying to solve a non-problem. And sometimes, 'specially on an upgraded machine, it's great to see how things WERE when the machine was set up. If you really care, go ahead, delete stuff. Nick.
Re: User who invoke doas
Nick Holland wrote: > > In a shell script invoked by doas, is it possible to find which user > > invoke the script? my search a the moment has come up empty. > > most likely place would be an environment variable, right? > > # echo "I started out as $LOGNAME" > I started out as nick Note that LOGNAME and other variables can be set by the user to indicate a different user name. $ env LOGNAME=somebody doas sh -c 'echo $LOGNAME' somebody
Re: Upgrade procedure (6.4 -> 6.5)
On 09:42 Thu 02 May, Stuart Henderson wrote: > The upgrade notes only list files which are likely to cause a problem > if they're left lying around. Oh, okay.
Re: Upgrade procedure (6.4 -> 6.5)
On 2019-05-02 11:46, Noth wrote:
> I set up a script for sysclean:
>
> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
Nitpick, but this could be shortened to:
xargs rm -rf < sysclean??.txt
Just tested this on my server, so it should work fine.
--
Stephen Gregoratto
PGP: 3FC6 3D0E 2801 C348 1C44 2D34 A80C 0F8E 8BAB EC8B
Re: User who invoke doas
On Thu, May 2, 2019 at 20:17, Nick Holland wrote: > On 5/1/19 10:28 PM, Adam Steen wrote: >> Hi >> >> In a shell script invoked by doas, is it possible to find which user >> invoke the script? my search a the moment has come up empty. > > most likely place would be an environment variable, right? > > So ... > > $ whoami > nick > > $ doas -s > > # whoami > root > > # env |grep nick > LOGNAME=nick > HOME=/home/nick > MAIL=/var/mail/nick > > PATH=/home/nick/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. > USER=nick > > # echo "I started out as $LOGNAME" > I started out as nick > > 'dar ya go. > > Nick. Awesome thanks Nick!
Re: Upgrade procedure (6.4 -> 6.5)
Hi Nick, Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400: > There is no promise that an upgraded machine will be file-for-file > identical to a fresh install. Here is the list of problems this might > cause you, as you can see, it's a long list and quite horrible: > > * If you use the same hw for 20 years, you might run out of disk space? > > Ok, not very long and not very horrible. > > You are trying to solve a non-problem. And sometimes, 'specially on an > upgraded machine, it's great to see how things WERE when the machine was > set up. If you really care, go ahead, delete stuff. There is (at least) one slight issue that doesn't have an official solution yet: manual pages. It might be a good idea to do # rm -rf /usr/share/man/* /usr/X11R6/man/* immediately before an upgrade. If you don't do that, man(1) might serve you stale manual pages afterwards that were removed from the sets, containing information that no longer applies. All the same, so far, we don't officially recommend it, and even i usually forget about it when doing upgrades. Should that be automated? Or are there risks of downsides or side effects? I'm not sure. Either way, it's hardly a very serious problem, it's merely slightly annoying. Yours, Ingo
Re: User who invoke doas
On Thu, May 02, 2019 at 04:29:20AM +, Adam Steen wrote: > > Hi > > In a shell script invoked by doas, is it possible to find which user > invoke the script? my search a the moment has come up empty. > > Cheers Adam > Hi Adam, Nowadays, I think the POSIX way is considered to be id(1) with appropriate args: id -nur (Untested) Regards, -- Frank https://woodcruft.co.uk/
Re: Upgrade procedure (6.4 -> 6.5)
Ingo Schwarze [schwa...@usta.de] wrote: > > It might be a good idea to do > > # rm -rf /usr/share/man/* /usr/X11R6/man/* > > immediately before an upgrade. > I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6 before a new snapshot is applied. This is a bit overkill but it's easier than trying to remember what subdirectories to include during any given release transition.
Re: Got hits Job offering in the mail
I’ve got it as well from a different random recruiter and it was addressed to the wrong name. I doubt that Apple is doing such unprofessional recruiting - It looks like some scam. Reyk > Am 02.05.2019 um 16:56 schrieb Dan Shechter : > > Got approached by a head hunter. > > If anyone in the community is interested and read it as is, I am just copy > pasting, and I know NOTHING about this job or the head hunter that sent me > the bellow email: > > Hii There! > > > > Greetings of the day!! > > > > I found your resume from one of the job portal and just want to check if > you are available for new opportunity and it seems really a good match with > the requirement so please have a look at the requirement and let me know if > you are comfortable with the requirement. If interested please revert back > with updated resume > > > > *JD : OpenBSD Resource* > > *Start Date: Immediate* > > *Location: Apple Park* > > > > > *Tasks:* > 1. Document the existing state of projects > - Diff versions in macOS vs released by project > - Public state of projects (how much active development, > direction, potential replacements, license status, etc.) > 2. Bring macOS forward > - Pull latest project versions in > - Review radars to determine what is fixed in latests > versions vs. is still a problem or is a new feature/enhancement request > - Fix high/medium impact issues > - Upstream changes, if possible and as appropriate > 3. Testing suite > - Integrate existing open source tests > - Develop new tests where there are gaps > 4. Automate the process > - Create a tool that will automate as much of the work as > possible > - Pull down latest repo, apply Apple-specific patches, > prep for submission to build > - Would be run on a set cadence relative to OS releases > 5. GPL replacements > - Develop BSD licensed replacements for any strategically > important projects that don’t currently have one > > > > > > > > Thanks & Regards, > > *Jack Thomson* > > *Talent Acquisition Team* > > *Ph: 732-200-1396* > > *2 N. Market St., #400, San Jose, CA, 95113* > > *jac...@e-solutionsinc.com* > > www.e-solutionsinc.com
Re: Got hits Job offering in the mail
Dan Shechter writes: > Greetings of the day!! Spam giveaway. No recruiter in the USA would use that phrase. That and the other grammatical and sentence structure errors are red flags. Allan
Re: User who invoke doas
On 5/2/19 8:04 AM, Ted Unangst wrote: > Nick Holland wrote: >> > In a shell script invoked by doas, is it possible to find which user >> > invoke the script? my search a the moment has come up empty. >> >> most likely place would be an environment variable, right? > >> >> # echo "I started out as $LOGNAME" >> I started out as nick > > Note that LOGNAME and other variables can be set by the user to indicate a > different user name. > > $ env LOGNAME=somebody doas sh -c 'echo $LOGNAME' > somebody And that's important -- I (silently) assumed a semi-friendly environment, not a good idea. Evaluate my suggestion based on your actual needs and risks. But then, if the wrong person has sudo access on your box, this may not be your biggest problem of the day. Nick.
user unable to log in xenodm / Xorg session | XIO fatal io error 35
SYMPTOM: Soon after a fresh OpenBSD install intended to use as a laptop / work engine, and consequently a few uses of a graphical session, suddenly the X session cannot start anymore : logging in with a correct user/passwd pair provokes a crash and restart of the X Display Manager, displaying the xdm login screen anew. But I can still log in xdm as root. Xorg.0.log https://pastebin.com/pZDf90TE xenodm.log https://pastebin.com/abjyLCyU dmesg.boot https://pastebin.com/T3UGucB1 (also attached) DIAGNOSTIC: A main relevant error seems to be (from xenodm.log) : 26 xenodm info (pid 30531): sourcing /etc/X11/xenodm/TakeConsole 27 XIO: fatal IO error 35 (Resource temporarily unavailable) on X server ":0" 28 after 128 requests (121 known processed) with 0 events remaining. TakeConsole file executes the sessreg(1) command. There is also a minor error listed in the Xorg.0.log file 345 [14.897] (EE) PreInit returned 2 for "/dev/wsmouse" I use a laptop that was assembled with Linux by an OEM in 2013. === This (being unable to log in a graphic session) has happened on all three OpenBSD installs I performed : ⋅ First on OpenBSD 6.4 run in a standard qemu x86_64 virtual machine. ⋅ Then on my recent installation of OpenBSD 6.4, which unrelatedly I also upgraded to the 6.5 version of the operating system. ⋅ Finally, on the subsequent fresh install of the latest OpenBSD 6.5 release (which the log files are from). It is quite frustrating. I suspect this might be triggered by an improper powering off of the system. (overall system as well as xenodm and the X session) Amusingly enough, a quick web search for the error returns three relevant results, two of which refer other operating systems : ⋅ The first is a thread, blank of replies, from Apple forums circa 2015 https://discussions.apple.com/thread/7356352 ⋅ Another is a guide to a tool designed to fix this error for Windows http://wiki-157727.usedtech.org/xio-fatal-io-error-35.html ⋅ Somebody on these very lists as far back as in 2011, on x11-devel =x11=201103/1 >From beasley Subject X11 crashes with fatal IO error 35 on old pentium I laptop DateThu, 03 Mar 2011 01:55:56 -0600 https://marc.info/?t=12991390632=1=2 OR http://openbsd-archive.7691.n7.nabble.com/X11-crashes-with-fatal-IO-error-35-on-old-pentium-I-laptop-td211423.html ⋅ Also a thread on stackexchange closed for vagueness https://unix.stackexchange.com/questions/250215/fatal-io-error-35-x-problem I'm hoping to fix this problem which makes the situation very impractical. Thank you, Sylvain S dmesg.boot Description: Binary data
Re: Upgrade procedure (6.4 -> 6.5)
Hi Chris, Chris Cappuccio wrote on Thu, May 02, 2019 at 12:08:07PM -0700: > Ingo Schwarze [schwa...@usta.de] wrote: >> It might be a good idea to do >> >> # rm -rf /usr/share/man/* /usr/X11R6/man/* >> >> immediately before an upgrade. > I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6 > before a new snapshot is applied. This is a bit overkill That may well be adequate for your personal needs, though we certainly can't make that the default. In particular, you are deleting /usr/X11R6/lib/ which means that many installed packages stop working, and also private programs that you may have compiled from source. Sure, you should run "pkg_add -u" anyway, and also recompile whatever you compiled by hand. All the same, for the average user, the expectation is that doing an upgrade will usually *not* result in programs linked against old libraries being broken - except, of course, in the case of major flag days described in upgrade*.html and current.html. Yours, Ingo > but it's easier than trying to remember what subdirectories to > include during any given release transition.
Re: Upgrade procedure (6.4 -> 6.5)
On 10:27 Thu 02 May, Markus Hennecke wrote: > Am 02.05.2019 um 09:52 schrieb Consus: > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > > that /etc/networks and some other files (like malloc.conf.5) are still > > present, although there is no use for them in the new release. > > > > Is there a reason why these files are not listed in "FIles to remove"? > > Is there a way to track them? It's not like something gonna break, but > > old configuration files (and manual pages) lying around can make > > someone's life harder during the debug session. > > Take a look at the sysutils/sysclean port. That's pretty much how I discovered this. But I want to know the "official" way. Maybe there is a reason why e.g. perl files are to be removed, but man pages are not.
Re: Upgrade procedure (6.4 -> 6.5)
On 2019-05-02, Consus wrote: > On 10:27 Thu 02 May, Markus Hennecke wrote: >> Am 02.05.2019 um 09:52 schrieb Consus: >> > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see >> > that /etc/networks and some other files (like malloc.conf.5) are still >> > present, although there is no use for them in the new release. >> > >> > Is there a reason why these files are not listed in "FIles to remove"? >> > Is there a way to track them? It's not like something gonna break, but >> > old configuration files (and manual pages) lying around can make >> > someone's life harder during the debug session. >> >> Take a look at the sysutils/sysclean port. > > That's pretty much how I discovered this. But I want to know the > "official" way. Maybe there is a reason why e.g. perl files are to be > removed, but man pages are not. > > The upgrade notes only list files which are likely to cause a problem if they're left lying around.
Re: Upgrade procedure (6.4 -> 6.5)
On 02/05/2019 11:02, Consus wrote:
On 10:27 Thu 02 May, Markus Hennecke wrote:
Am 02.05.2019 um 09:52 schrieb Consus:
I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
that /etc/networks and some other files (like malloc.conf.5) are still
present, although there is no use for them in the new release.
Is there a reason why these files are not listed in "FIles to remove"?
Is there a way to track them? It's not like something gonna break, but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.
Take a look at the sysutils/sysclean port.
That's pretty much how I discovered this. But I want to know the
"official" way. Maybe there is a reason why e.g. perl files are to be
removed, but man pages are not.
I set up a script for sysclean:
cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
sysclean65.txt is obtained by running sysclean -a >>sysclean65.txt . I
don't run that line in sysclean65.sh because the files have to be
reviewed to prevent deletion of any additional files you may have added,
like certs or scripts.
HTH
Noth
