Instructions for El Capitan #3999

Merged
merged 3 commits into from Oct 1, 2015

Conversation

Projects
None yet
9 participants
@chrisfinazzo
Contributor

chrisfinazzo commented Sep 27, 2015

No description provided.

@parkr

View changes

site/_docs/troubleshooting.md
+[rbenv]: http://rbenv.org
+[chruby]: https://github.com/postmodern/chruby
+
+If you elect to use a method other than Homebrew to install Ruby, it may be

This comment has been minimized.

@parkr

parkr Sep 28, 2015

Member

Home brew seems to come out of the blue here. Is it mentioned above? I'm on mobile and can't check easily.

Additionally, we could say "other than Homebrew to install Ruby, such as those listed above, ..." To clarify that they are ruby managers

@parkr

parkr Sep 28, 2015

Member

Home brew seems to come out of the blue here. Is it mentioned above? I'm on mobile and can't check easily.

Additionally, we could say "other than Homebrew to install Ruby, such as those listed above, ..." To clarify that they are ruby managers

This comment has been minimized.

@chrisfinazzo

chrisfinazzo Sep 28, 2015

Contributor

I realized almost as soon as I wrote the words that something just didn't sound right. Homebrew is mentioned without really any introduction or explanation at all. My thinking came out of @chmaynard's comment and a follow up I added. While I think most people who get this far likely would understand it, I agree it's really not supported well and needs to be rephrased.

To your second point, that seems like a much clearer transition - I'll give it some thought and see how this can be incorporated...

@chrisfinazzo

chrisfinazzo Sep 28, 2015

Contributor

I realized almost as soon as I wrote the words that something just didn't sound right. Homebrew is mentioned without really any introduction or explanation at all. My thinking came out of @chmaynard's comment and a follow up I added. While I think most people who get this far likely would understand it, I agree it's really not supported well and needs to be rephrased.

To your second point, that seems like a much clearer transition - I'll give it some thought and see how this can be incorporated...

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Sep 28, 2015

Member

In general, 👍!

Member

parkr commented Sep 28, 2015

In general, 👍!

@parkr parkr referenced this pull request in github/pages-gem Sep 28, 2015

Closed

Failed to build gem native extension #133

@alfredxing

This comment has been minimized.

Show comment
Hide comment
@alfredxing

alfredxing Sep 29, 2015

Member

👍
 

It is recommended that you choose one of a number of Ruby version managers

Though my personal experience of using Ruby on OS X (I'm running El Cap on one of my machines) is that using a Ruby manager just isn't worth the hassle for most people. There are some people who need multiple Ruby versions but for someone who only needs one version at a time, Homebrew works great. It's always nice to get Ruby updates when you run the occasional brew upgrade, rather than needing a whole separate Ruby manager.

Just my two cents!

Member

alfredxing commented Sep 29, 2015

👍
 

It is recommended that you choose one of a number of Ruby version managers

Though my personal experience of using Ruby on OS X (I'm running El Cap on one of my machines) is that using a Ruby manager just isn't worth the hassle for most people. There are some people who need multiple Ruby versions but for someone who only needs one version at a time, Homebrew works great. It's always nice to get Ruby updates when you run the occasional brew upgrade, rather than needing a whole separate Ruby manager.

Just my two cents!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 29, 2015

I have been following this thread with interest, and I agree that installing into ~/bin is a good approach. However, I still strongly recommend using the Homebrew package manager. IMHO, the typical Jekyll user on OS X is (or should be) using Homebrew anyway, especially if there are several accounts on the same machine.

On Sep 28, 2015, at 10:21 PM, Alfred Xing notifications@github.com wrote:

it is recommended that you choose one of a number of Ruby version managers

Though my personal experience of using Ruby on OS X (I'm running El Cap on one of my machines) is that using a Ruby manager just isn't worth the hassle for most people. There are some people who need multiple Ruby versions but for someone who only needs one version at a time, Homebrew works great. It's always nice to get Ruby updates when you run the occasional brew upgrade, rather than needing a whole separate Ruby manager.

Just my opinion!


Reply to this email directly or view it on GitHub #3999 (comment).

ghost commented Sep 29, 2015

I have been following this thread with interest, and I agree that installing into ~/bin is a good approach. However, I still strongly recommend using the Homebrew package manager. IMHO, the typical Jekyll user on OS X is (or should be) using Homebrew anyway, especially if there are several accounts on the same machine.

On Sep 28, 2015, at 10:21 PM, Alfred Xing notifications@github.com wrote:

it is recommended that you choose one of a number of Ruby version managers

Though my personal experience of using Ruby on OS X (I'm running El Cap on one of my machines) is that using a Ruby manager just isn't worth the hassle for most people. There are some people who need multiple Ruby versions but for someone who only needs one version at a time, Homebrew works great. It's always nice to get Ruby updates when you run the occasional brew upgrade, rather than needing a whole separate Ruby manager.

Just my opinion!


Reply to this email directly or view it on GitHub #3999 (comment).

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 29, 2015

Contributor

From a systems standpoint that logic is broken, if you have multiple users on the same computer using the same software it would be more prudent to do a system wide install and have them install gems in their home directory and if jekyll is a common denominator then install Jekyll system wide too, but either way we are not on about logical systems management anyways we are on about OS X and their changed systems protection mechanisms that go a bit wild.

Contributor

envygeeks commented Sep 29, 2015

From a systems standpoint that logic is broken, if you have multiple users on the same computer using the same software it would be more prudent to do a system wide install and have them install gems in their home directory and if jekyll is a common denominator then install Jekyll system wide too, but either way we are not on about logical systems management anyways we are on about OS X and their changed systems protection mechanisms that go a bit wild.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Sep 29, 2015

Member

Let's do this:

Simply recommend Homebrew and give the copy-and-paste command to install and setup Homebrew and Ruby via Homebrew. Mention for "advanced users" that Ruby Version Managers are also acceptable. Ensure gem install can be run without sudo.

Any objections?

Member

parkr commented Sep 29, 2015

Let's do this:

Simply recommend Homebrew and give the copy-and-paste command to install and setup Homebrew and Ruby via Homebrew. Mention for "advanced users" that Ruby Version Managers are also acceptable. Ensure gem install can be run without sudo.

Any objections?

@parkr parkr added the Documentation label Sep 29, 2015

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 29, 2015

Here's my personal checklist for installing Jekyll on OS X:

  • Install Xcode command line utilities xcode-select --install
  • Install Homebrew (instructions at http://brew.sh)
  • Modify $PATH to use Homebrew export PATH=/usr/local/bin:$PATH
  • Install the latest Ruby brew install ruby
  • Install the latest Jekyll gem install jekyll

ghost commented Sep 29, 2015

Here's my personal checklist for installing Jekyll on OS X:

  • Install Xcode command line utilities xcode-select --install
  • Install Homebrew (instructions at http://brew.sh)
  • Modify $PATH to use Homebrew export PATH=/usr/local/bin:$PATH
  • Install the latest Ruby brew install ruby
  • Install the latest Jekyll gem install jekyll
@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Sep 29, 2015

Contributor

@parkr, OK, will update.

When finished, is it preferable that I squash this into 1 commit for the merge?

Contributor

chrisfinazzo commented Sep 29, 2015

@parkr, OK, will update.

When finished, is it preferable that I squash this into 1 commit for the merge?

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Sep 29, 2015

Member

When finished, is it preferable that I squash this into 1 commit for the merge?

If you're comfortable with that. I'm ok merging commits that have detailed/useful commit messages and encapsulate useful changes.

Member

parkr commented Sep 29, 2015

When finished, is it preferable that I squash this into 1 commit for the merge?

If you're comfortable with that. I'm ok merging commits that have detailed/useful commit messages and encapsulate useful changes.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 29, 2015

Contributor

True that, the only time I think a squash needs to happen is if there are simple corrections, otherwise additions can be their own commits to help people see evolution.

Contributor

envygeeks commented Sep 29, 2015

True that, the only time I think a squash needs to happen is if there are simple corrections, otherwise additions can be their own commits to help people see evolution.

@connorshea

This comment has been minimized.

Show comment
Hide comment
@connorshea

connorshea Sep 30, 2015

+1 especially now that El Capitan has been released to the public.

+1 especially now that El Capitan has been released to the public.

@r3id

This comment has been minimized.

Show comment
Hide comment
@r3id

r3id Oct 1, 2015

So does this mean that it's no longer a simple install process like under Yosemite?

r3id commented Oct 1, 2015

So does this mean that it's no longer a simple install process like under Yosemite?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Oct 1, 2015

Contributor

@r3id it seems that is the case because of the new over zealous system protections.

Contributor

envygeeks commented Oct 1, 2015

@r3id it seems that is the case because of the new over zealous system protections.

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Oct 1, 2015

Contributor

@envygeeks Overzealous? That's a bit harsh don't you think? Was it ever a good idea or reasonable security practice to allow an entity other than Apple to modify system files, inject code into another process, or attach unknown runtimes?

The answer to all of these questions is unequivocally no.

Contributor

chrisfinazzo commented Oct 1, 2015

@envygeeks Overzealous? That's a bit harsh don't you think? Was it ever a good idea or reasonable security practice to allow an entity other than Apple to modify system files, inject code into another process, or attach unknown runtimes?

The answer to all of these questions is unequivocally no.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Oct 1, 2015

Contributor

@chrisfinazzo yes:

  1. It's my system, I will do as I please, when I'm pleased to do it.
  2. It's my system, I will do as I please, when I'm pleased to do it.
  3. It's my system, I will do as I please, when I'm pleased to do it.
  4. It's my system, I will do as I please, when I'm pleased to do it.
  5. It's my system, I will do as I please, when I'm pleased to do it.
  6. dylib, heard of it? I can still inject code if you don't protect against it yourself.
  7. There ways to stop process attachment without going overzealous and preventing advanced users from doing what they want. The Linux kernel does it, and has for at least as long as I can remember (as far as like 8 years ago is when I first encountered the ability to prevent unpriviledged unowned process attachment.) I can sudo into root and attach to what I want and that's what should be allowed. If it's not, it's overzealous. I don't know what I said has to do with this anyways because this is probably still possible with sudo.

If none of those can be worked around for advanced users, it's overzealous, it's limiting and it's not very fostering to what computers initially existed for in the first place and it's a slap in the face. I will say though I'm not convinced you can't sudo out of it, I've not played with it yet to see what the state of their new system protection is but I do know that unless they do some serious hardening a few of the things you listed will still be possible within that users land unless they remove core pieces of the languages they rely on.

Contributor

envygeeks commented Oct 1, 2015

@chrisfinazzo yes:

  1. It's my system, I will do as I please, when I'm pleased to do it.
  2. It's my system, I will do as I please, when I'm pleased to do it.
  3. It's my system, I will do as I please, when I'm pleased to do it.
  4. It's my system, I will do as I please, when I'm pleased to do it.
  5. It's my system, I will do as I please, when I'm pleased to do it.
  6. dylib, heard of it? I can still inject code if you don't protect against it yourself.
  7. There ways to stop process attachment without going overzealous and preventing advanced users from doing what they want. The Linux kernel does it, and has for at least as long as I can remember (as far as like 8 years ago is when I first encountered the ability to prevent unpriviledged unowned process attachment.) I can sudo into root and attach to what I want and that's what should be allowed. If it's not, it's overzealous. I don't know what I said has to do with this anyways because this is probably still possible with sudo.

If none of those can be worked around for advanced users, it's overzealous, it's limiting and it's not very fostering to what computers initially existed for in the first place and it's a slap in the face. I will say though I'm not convinced you can't sudo out of it, I've not played with it yet to see what the state of their new system protection is but I do know that unless they do some serious hardening a few of the things you listed will still be possible within that users land unless they remove core pieces of the languages they rely on.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Oct 1, 2015

Member

Personal feelings about systems aside, this PR is looking pretty good.

The process is still the same once a non-system Ruby is installed on your El Capitan machine.

Member

parkr commented Oct 1, 2015

Personal feelings about systems aside, this PR is looking pretty good.

The process is still the same once a non-system Ruby is installed on your El Capitan machine.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Oct 1, 2015

Contributor

I'm 👍

Contributor

envygeeks commented Oct 1, 2015

I'm 👍

parkr added a commit that referenced this pull request Oct 1, 2015

@parkr parkr merged commit a1fdf83 into jekyll:master Oct 1, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

parkr added a commit that referenced this pull request Oct 1, 2015

@chrisfinazzo chrisfinazzo deleted the chrisfinazzo:instructions-for-el-capitan branch Oct 1, 2015

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Oct 1, 2015

Contributor

Woah.

Although this is resolved now, I should clarify. To your 3 categories of complaints:

  • Fine. It's your machine, go to town. Just be careful out there.
  • I have. This was fixed in August as part of the 10.10.5 update and (I assume) rolled into 10.11. If it should pop up again, at the very least it is a known quantity. There is another recent exploit which messes with privilege escalation, so they aren't perfect, but at these these issues aren't being ignored.
  • To your last point, there'a pretty deep dive into things as part of Ars' El Capitan review which should address most of those concerns. The basic gist of it is that there is no GUI for this and you have to boot the Recovery OS to get a terminal which will accept the relevant commands - including one which will disable the feature if you so desire.
Contributor

chrisfinazzo commented Oct 1, 2015

Woah.

Although this is resolved now, I should clarify. To your 3 categories of complaints:

  • Fine. It's your machine, go to town. Just be careful out there.
  • I have. This was fixed in August as part of the 10.10.5 update and (I assume) rolled into 10.11. If it should pop up again, at the very least it is a known quantity. There is another recent exploit which messes with privilege escalation, so they aren't perfect, but at these these issues aren't being ignored.
  • To your last point, there'a pretty deep dive into things as part of Ars' El Capitan review which should address most of those concerns. The basic gist of it is that there is no GUI for this and you have to boot the Recovery OS to get a terminal which will accept the relevant commands - including one which will disable the feature if you so desire.
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 8, 2015

From p. 6 of Apple's System Integrity Protection Guide:

Developers using Perl, Python, Ruby, or any other scripting languages that ship with OS X, are encouraged to manage their own installations of the language and dependencies in /usr/local/.

In other words, Apple is locking down /usr and encouraging users to install into /usr/local/. Hopefully, a clean installation of El Capitan contains /usr/local/. If not, Apple screwed up.

ghost commented Oct 8, 2015

From p. 6 of Apple's System Integrity Protection Guide:

Developers using Perl, Python, Ruby, or any other scripting languages that ship with OS X, are encouraged to manage their own installations of the language and dependencies in /usr/local/.

In other words, Apple is locking down /usr and encouraging users to install into /usr/local/. Hopefully, a clean installation of El Capitan contains /usr/local/. If not, Apple screwed up.

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Oct 11, 2015

Contributor

@chmaynard,

I've read through the guide and unfortunately I can't confirm whether or not /usr/local is present if you're coming from 10.10 (haven't upgraded yet). However, it seems that Apple is subtly encouraging people to do one of two things.

You may:

  1. Use Homebrew to get /usr/local. The last time I did a setup (on 10.9), the install script still needed to do chown on this location, but with SIP in play, it seems like this is acceptable behavior and Apple won't mess with it in future updates. Never mind that the README practically begs you to install the standard way...
  2. Create the structure manually if it doesn't exist already. It's a known convention on UNIX and elsewhere. It is expected that people will want to do this.
Contributor

chrisfinazzo commented Oct 11, 2015

@chmaynard,

I've read through the guide and unfortunately I can't confirm whether or not /usr/local is present if you're coming from 10.10 (haven't upgraded yet). However, it seems that Apple is subtly encouraging people to do one of two things.

You may:

  1. Use Homebrew to get /usr/local. The last time I did a setup (on 10.9), the install script still needed to do chown on this location, but with SIP in play, it seems like this is acceptable behavior and Apple won't mess with it in future updates. Never mind that the README practically begs you to install the standard way...
  2. Create the structure manually if it doesn't exist already. It's a known convention on UNIX and elsewhere. It is expected that people will want to do this.
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 11, 2015

@chrisfinazzo In case you haven't seen it, here's a Homebrew article on El Capitan. Not sure why Homebrew decided to recommend chown /usr/local instead of simply changing the permissions.

ghost commented Oct 11, 2015

@chrisfinazzo In case you haven't seen it, here's a Homebrew article on El Capitan. Not sure why Homebrew decided to recommend chown /usr/local instead of simply changing the permissions.

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Oct 11, 2015

Contributor

Yeah, I saw that too, good to know that the maintainers already have a procedure for this. Reading it again makes me think that Option 2 might not work even if it is a known location - which is kind of a shame for people who like to do things using make where you might prefix /usr/local as the destination.

chmod is really the more appropriate choice, guess I just forgot...like I said, it's been a while since I did this last.

Contributor

chrisfinazzo commented Oct 11, 2015

Yeah, I saw that too, good to know that the maintainers already have a procedure for this. Reading it again makes me think that Option 2 might not work even if it is a known location - which is kind of a shame for people who like to do things using make where you might prefix /usr/local as the destination.

chmod is really the more appropriate choice, guess I just forgot...like I said, it's been a while since I did this last.

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 11, 2015

Not sure why Homebrew decided to recommend chown /usr/local instead of simply changing the permissions.

Homebrew doesn't mandate sudo and the permissions on OS X El Cap for /usr/local seem to be set as root:wheel in line with the rest of /usr, albeit with the caveat that users can actually change the permissions on /usr/local.

DomT4 commented Oct 11, 2015

Not sure why Homebrew decided to recommend chown /usr/local instead of simply changing the permissions.

Homebrew doesn't mandate sudo and the permissions on OS X El Cap for /usr/local seem to be set as root:wheel in line with the rest of /usr, albeit with the caveat that users can actually change the permissions on /usr/local.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Oct 11, 2015

Contributor

@DomT4 /usr/local is supposed to be owned by root because it's in the default path and changing the permissions or owner could put your system at risk because then anybody who has direct write to that folder can shiv system binaries with bad ones easily. That to me seems like a security risk.

Contributor

envygeeks commented Oct 11, 2015

@DomT4 /usr/local is supposed to be owned by root because it's in the default path and changing the permissions or owner could put your system at risk because then anybody who has direct write to that folder can shiv system binaries with bad ones easily. That to me seems like a security risk.

@DomT4

This comment has been minimized.

Show comment
Hide comment
@DomT4

DomT4 Oct 12, 2015

Most Macs are also single-user with that user having admin rights, which somewhat takes the edge off an argument around "Gaining access to root could be a disaster", certainly prior to El Cap. Unless you're using OS X 10.11 there's also at least two exploits out there that'll give you full root access with little effort, as @chrisfinazzo references.

Apple really hasn't pushed privileged user separation in the same way Linux has encouraged, and SIP is almost the first big acceptance that people running as the admin user constantly is an issue, but we're barely into the SIP timetable and documentation is minimal. Trying to read Apple's mind on the direction of the changes going forwards is a fairly fruitless endeavour until we actually get to drive down this road a bit.

Homebrew doesn't recommend installing it there if the system is multi-user, and as ever people get to pick their prefixes by just git clone-ing it somewhere else. Homebrew doesn't even block the user from running the entire party as root, if they really want to. There may be a default, but people aren't bound by it.

DomT4 commented Oct 12, 2015

Most Macs are also single-user with that user having admin rights, which somewhat takes the edge off an argument around "Gaining access to root could be a disaster", certainly prior to El Cap. Unless you're using OS X 10.11 there's also at least two exploits out there that'll give you full root access with little effort, as @chrisfinazzo references.

Apple really hasn't pushed privileged user separation in the same way Linux has encouraged, and SIP is almost the first big acceptance that people running as the admin user constantly is an issue, but we're barely into the SIP timetable and documentation is minimal. Trying to read Apple's mind on the direction of the changes going forwards is a fairly fruitless endeavour until we actually get to drive down this road a bit.

Homebrew doesn't recommend installing it there if the system is multi-user, and as ever people get to pick their prefixes by just git clone-ing it somewhere else. Homebrew doesn't even block the user from running the entire party as root, if they really want to. There may be a default, but people aren't bound by it.

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.