Re: /usr/libexec/path_helper problem
It suddenly struck me what the difference between the systems are : The two computers with the problems have SSDs and Apple_APFS without any issues have "Spinning Rust" and Apple_HFS -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
Jan Stary wrote: > I don't get it. 10.13.2 does _not_ have a root account by default? Why? > And if it does, how is that a problem? It's UNIX, of course there is > a 'root' account. macOS out-of-the-box has a de-activated root account; eg you can't log in as root or ssh into the box as root. The root account exists but in a dormant state and is accessed though sudo from admin accounts. One of the things I do on my boxes is activating the root account; and in some cases removing the other admin accounts, so I've only got root and users. Now, if the root account is de-activated you have no way of administering the box - even with sudo at normal user accounts can't use sudo. Also if you have scrips that eg ssh into the box from the outside, this will completely thow off your setup. -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
On Jan 15 10:21:05, macint...@mathiesen.info wrote: > Jan Stary wrote: > > I don't get it. 10.13.2 does _not_ have a root account by default? Why? > > And if it does, how is that a problem? It's UNIX, of course there is > > a 'root' account. > > macOS out-of-the-box has a de-activated root account; eg you can't log > in as root or ssh into the box as root. The root account exists but in a > dormant state and is accessed though sudo from admin accounts. That seems like a sensible default. > One of the things I do on my boxes is activating the root account; Meaning that you can now do what? Login as root on a console? Login as root via ssh? > and in some cases removing the other admin accounts, Why? > so I've only got root and users. Meaning: users that can't su to root? > Now, if the root account is de-activated Is _that_ the problem you are talking about? i.e. Apple 'disables' the rot account with the udate? > you have no way of administering the box > - even with sudo at normal user accounts can't use sudo. Well, keep yourself being admin then. > Also if you have scrips that eg ssh into the box from the outside, > this will completely thow off your setup. You have scripts that remotely log in as root? Jan
Re: 10.13.2 supplemental update & root account
Jan Stary wrote: > On Jan 15 10:21:05, macint...@mathiesen.info wrote: >> One of the things I do on my boxes is activating the root account; > > Meaning that you can now do what? > Login as root on a console? > Login as root via ssh? > >> and in some cases removing the other admin accounts, > > Why? When root is activated, there's no need for a normal admin account > >> so I've only got root and users. > > Meaning: users that can't su to root? correct > >> Now, if the root account is de-activated > > Is _that_ the problem you are talking about? > i.e. Apple 'disables' the root account with the udate? yes > >> you have no way of administering the box >> - even with sudo at normal user accounts can't use sudo. > > Well, keep yourself being admin then. why ? Apple shouldn't disable the root account through a supplementary update when I've chosen to activate it. They have _never_ done this before ! > >> Also if you have scrips that eg ssh into the box from the outside, >> this will completely thow off your setup. > > You have scripts that remotely log in as root? presently no but I ssh into my boxes as root in order to admin them there's stuff I can only access as root - eg the postfix and dovecot logs -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
As I understood the description of the patch/update — the Root Account is only de-activated if it has no password. Making it just like all previous releases of OSX. If you have activated the Root Account and supplied a password, then nothing happens. Read Mac Rumors description: https://www.macrumors.com/2017/11/29/apple-fixes-root-password-bug-security-update/ The original bug description: https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-admin-access/ > On Jan 15, 2018, at 4:21 AM, Bjarne D Mathiesen > wrote: > > Jan Stary wrote: >> I don't get it. 10.13.2 does _not_ have a root account by default? Why? >> And if it does, how is that a problem? It's UNIX, of course there is >> a 'root' account. > > macOS out-of-the-box has a de-activated root account; eg you can't log > in as root or ssh into the box as root. The root account exists but in a > dormant state and is accessed though sudo from admin accounts. > > One of the things I do on my boxes is activating the root account; and > in some cases removing the other admin accounts, so I've only got root > and users. Now, if the root account is de-activated you have no way of > administering the box - even with sudo at normal user accounts can't use > sudo. > > Also if you have scrips that eg ssh into the box from the outside, this > will completely thow off your setup. > > -- > Bjarne D Mathiesen > Korsør ; Danmark ; Europa > -- > denne besked er skrevet i et totalt M$-frit miljø > macOS 10.13.2 High Sierra (17C205) > 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC > ATI Radeon HD 5770 1024 MB "Never be cruel; never be cowardly; and never ever eat pears.” - The Doctor William H. Magill mag...@icloud.com whmag...@gmail.com
Re: 10.13.2 supplemental update & root account
On Jan 15 13:39:34, macint...@mathiesen.info wrote: > Apple shouldn't disable the root account through a supplementary update > when I've chosen to activate it. They have _never_ done this before ! I agree that Apple shouldn't be touching the users setup, such as enable/disable account's login. But they do, because they are Apple. Obey. > >> Also if you have scrips that eg ssh into the box from the outside, > >> this will completely thow off your setup. > > > > You have scripts that remotely log in as root? > > presently no > but I ssh into my boxes as root in order to admin them > there's stuff I can only access as root - eg the postfix and dovecot logs That's exactly what the 'wheel' group is for in UNIX, or why 'admin' accounts are for in MacOS, right? Jan
Re: 10.13.2 supplemental update & root account
William H. Magill wrote: > As I understood the description of the patch/update — the Root Account is > only de-activated if it has no password. > Making it just like all previous releases of OSX. It wasn't an issue of having an _active_ root account The root account wasn't active; but you could still use it in System Preferences > Users & Groups ; and because it wasn't active, it had no password - leading to the security blunder and a local exploit > > If you have activated the Root Account and supplied a password, then nothing > happens. Nope - 16 character long non-obvious strong password still de-activated :-( I only installed 10.13 when 10.13.2 was released and my root accounts 'survived' that update from 10.12 without any problems at all But the 10.13.2 supplementary update de-activates the root account And that update should only have something to do with Spectre and Safari/WebKit > > Read Mac Rumors description: > https://www.macrumors.com/2017/11/29/apple-fixes-root-password-bug-security-update/ > > The original bug description: > https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-admin-access/ > -- Bjarne D Mathiesen Korsør ; Danmark ; Europa -- denne besked er skrevet i et totalt M$-frit miljø macOS 10.13.2 High Sierra (17C205) 2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC ATI Radeon HD 5770 1024 MB
Re: 10.13.2 supplemental update & root account
On Jan 14, 2018, at 19:26, Bjarne D Mathiesen wrote: > The 10.13.2 supplemental update in-activates the root account if enabled > Luckily, on the machines I've updated, I also had a normal admin > account, so no big deal ; but I also have a machine with no normal admin > account, so if it does that on that one also, it'll be a hell of a > problem getting an admin account again (I do know how to do it) Using the root account is not recommended; you should use an admin account instead. If you must use the root account, and you have no admin account with which to enable it the normal way, you can apparently enable it in single user mode: http://sachinparmarblog.com/enable-root-user-password-in-single-user-mode/
Re: binary packages for 10.5.8
On Jan 14, 2018, at 14:47, Mojca Miklavec wrote: > On 14 January 2018 at 11:40, Chris Jones wrote: >> >> A buildbot exists for PPC, but not intel >> >> The assumption I believe being if you have an intel machine, you should >> update at least to 10.6... the 10.5 buildbot exists because that is the last >> OS supporting PPC machines. > > There is no special reason for *not* having the 10.5/intel bot > available except that the demand for it is pretty low and each > buildbot consumes some resources and nobody bothered adding it. The reasons for not having a 10.5 Intel builder are that no users should need it (all users on 10.5 Intel should upgrade to 10.6) and the packages it would create would take up disk space on all mirrors; we have already had one MacPorts mirror leave because they could no longer accommodate our disk space requirements.
Re: MacPorts has stopped running
On Jan 13, 2018, at 16:02, Tom Scott wrote: > I sorry to send this question to you directly but my Macports question seems > not to fit into the unusual cases so I’m not quite sure where to direct it. > > I’m using MacOS high Sierra 10.13.2 and prior to installing Macports Xcode > 9.2 was installed. Macports was successfully installed with the downloaded > package installer. Initially Macports worked fine and several ports were > also successfully installed. But after installing further software including > IRAF (sucessfully) and KARMA (unsuccessfully so far), Macports and the > installed ports have ceased to work, e.g. > > toms-MacBook-Pro:~ tomscott$ port version > -bash: port: command not found This means the "port" command is not in any directory in your PATH. Lenore has a good theory: On Jan 14, 2018, at 08:13, Lenore Horner wrote: > I managed to achieve something similar the other day by creating a > .bash_profile which then got read instead of my .profile that had my MacPorts > path changes. That was my first inclination as well. I don't know what IRAF and KARMA are, but maybe they're responsible for creating (or instructing you to create) a .bash_profile or .bash_login file. Since you use bash, it doesn't matter whether you name your shell init file .profile or .bash_profile or .bash_login, but you should pick just one. Put all of the lines from all of those files into one of the files and then delete the other file(s). > Also here is the content o the usr/local directory: > toms-MacBook-Pro:local tomscott$ pwd > /usr/local > toms-MacBook-Pro:local tomscott$ ls > bin include karma lib man > remotedesktop share texlive > toms-MacBook-Pro:local tomscott$ I don't know what's in those bin, include, lib directories. They're not causing this PATH problem, but depending on what's in there they can cause you other problems down the road. See: https://trac.macports.org/wiki/FAQ#usrlocal > I’m not sure how to proceed, e.g., would be be harmful to reinstall Macport > using the package installer again with out removing the current version or > might there be easier ways to try first to get Macports and its ports to run > again? Any help would be much appreciated. Running the MacPorts installer again will reinstall the MacPorts base files and rerun the shell setup. It will not affect your installed ports. For the shell setup, the installer checks whether you have a .bash_profile file, and if so, adds the MacPorts PATH modifications to it. Otherwise, it checks if you have a .bash_login, and it so, adds to that. Otherwise, it adds to .profile. So the problem could be that you didn't have a .bash_profile or .bash_login when you initially installed MacPorts, so it modified your .profile. And now for some reason you do have a .bash_profile or .bash_login, which bash is using instead of the .profile. If so, running the MacPorts installer again will fix up your .bash_profile or .bash_login file by adding the MacPorts PATH modifications to it. But you can also just fix it up manually.
Re: binary packages for 10.5.8
On 16 January 2018 at 05:33, Ryan Schmidt wrote: > > The reasons for not having a 10.5 Intel builder are that no users should need > it (all users on 10.5 Intel should upgrade to 10.6) and the packages it would > create would take up disk space on all mirrors; we have already had one > MacPorts mirror leave because they could no longer accommodate our disk space > requirements. Maybe we could one day provide "big size" and "small size" mirror sources. The mirrors which can only accommodate small size would then only mirror the latest two releases and make sure not to include any outdated distfiles whatsoever. I'm not saying this in support of 10.5, but unless we start removing 10.6 binaries and so on, our archives will just keep growing each year. The number of users who need the old binaries is relatively small compared to those who need one of the latest two, so it should be sufficient to serve those binaries from a smaller number of mirrors. Mojca
