I re-installed CommandBox using HomeBrew on my Mac...
# box-products
t
I re-installed CommandBox using HomeBrew on my Mac. This went ok. I started it with the box cmd and then installed commandbox-hostupdater which modifies the hosts file. I then started an adobe 2018 server with the "start cfengine=adobe@2018" to make sure the initial server start picked up that version of CF. But the password prompt was obscured so I didn't understand at the time that it was wanting my password to access the hosts file. It's not clear how to get the hosts file editable by CommandBox using the hostupdater pkg when edutubg tge hosts file requires root access. Any help in getting this to work would be appreciated. I'm using port 9001 for my dev project server. Here's a transcript of the attempt:
Copy code
CommandBox> start
|  sword: |ng Server
bash: /private/etc/hosts: Permission denied
bash: /private/etc/hosts: Permission denied
bash: /private/etc/hosts: Permission denied
 Ɨ | Starting Server
   |------------------------------   | Adding host 'sb' to your hosts file!   | Oh my! Something went wrong when trying to modify the hosts file!
   | Adding host '<http://dev.sb|dev.sb>' to your hosts file!
   | Oh my! Something went wrong when trying to modify the hosts file!
   | Adding host 'sb.local' to your hosts file!
   | Oh my! Something went wrong when trying to modify the hosts file!
   |------------------------------
   | √ | Setting Server Profile to [production]


ERROR (5.5.1+00562)

The host name [sb] can't be found. Do you need to add a host file entry?

sb
e
There's a PR that I opened that gets it working on macs again. https://github.com/chrisschmitz/commandbox-hostupdater/pull/24
b
@chris-schmitz ā˜ļø
@elpete Does your pull specifically fix the "permission denied" error @teaman is getting?
c
@elpete sorry, I was ill recently (caught the stupid virus) and am still catching up on things. Will look into your PR this week
e
Yes
šŸ‘ 1
b
That's interesting-- what does passing it through
sh
do to change it?
c
@teaman you need root privileges in order to edit the hosts file. That means you need to start commandbox with root privileges, i.e.
sudo ./box
b
Especially since CommandBox itself is already running the native calls through the local shell
e
Your code has prompted for sudo before, Chris. You shouldn't run as sudo in *nix environments because it runs as the root user in a root home folder. When you switch back to your user it doesn't have the same servers or modules.
@bdw429s I don't remember exactly. I found it on a stack overflow article about sudo and recent versions of macOS and it worked. ĀÆ\_(惄)_/ĀÆ
c
actually I haven't used commandbox in quite a while, so I don't remember exactly how it was... but there is a variable that you set in order to assign a directory where to store data,
COMMANDBOX_HOME
I believe
right.. you create a file
commandbox.properties
and in there you specify
commandbox_home=your-path
that's how I avoided the different servers and modules
e
In using it recently I could use it as my normal user and it would prompt for a password when needed.
c
you did that in your PR?
b
@chris-schmitz I've offered this before, but if you are short on time, Ortus will gladly take over the hostupdater module for you. It's important to us and our clients so we need to make sure we can get fixes in a timely manner šŸ™‚
The
commandbox.properties
trick is for pinning the CommandBox home regardless of the user, which is handy if you're running as root some times. It's sort of unrelated to the password prompt stuff since it is a valid use case for a user like Eric to not want to run as root, which can have other considerations.
My favorite fix for this on Linux is to allow my user to do passwordless sudo, but I realize not everyone wants that either.
c
@bdw429s Brad, now that you're saying it I dimly remember šŸ˜‰ Let me look into the PR this week and then I'll get back to you on the offer
t
@bdw429s @chris-schmitz @elpete Ok now I'm confused. is the PR the solution or is sudo box the solution? My .CommandBox home is in ~ (that's my user directory on MacOS). I usually cd to my project top level folder and in VSCode termimal, issue box cmd, then in box, start cmd. Voila i'm up and running my project. In this case I'm mapping my port 9001 to be my project root folder using a remapped domain "sb". So I type sb:9001 in my url and there's my project home. But it's that remapping sb domain at 9001 going into the hosts file that's balking now that i moved .CommandBox out of /private/var/root.
I would test but not in a position at the moment to test the solutions.
e
I use the same flow as you and the PR solved it for me.
t
I have tried the PR @elpete referred to at GitHub but it didn't resolve my permission denied issue. I also tried starting box using sudo but that just installs .CommandBox in /var/root where I don't want it to live and where I mentioned I uninstalled it by rm -r /var/root/.CommandBox/
@chris-schmitz @bdw429s So I'm not sure what the solution to this problem is any more. It's not clear if or how the setting of the commandbox_home path in commandbox.properties fixes this. Please explain if that should resolve.
c
@teaman using the
commandbox_home
approach you can tell Commandbox to store it's data wherever you want, no matter how you start it. I agree that this is not the optimal solution, but that's how I always did it.
t
@chris-schmitz Do you use sudo to start box, too, so that it avoids the permission issue?
c
@teaman, as I said before, I haven't really used CB for a few years, but yes, I remember I used
sudo
to start it. Just make sure that before the first start you create
commandbox.properties
with a path for
commandbox_home
in it. That path will be valid for ALL users of commandbox, so it doesn't matter whether you use
sudo
to start it or not
t
Ok. Where does that .properties file live?
b
@teaman Check out the instillation page in the CommandBox docs. This is all answered for you there šŸ™‚
Once you've pinned the CommandBox home to the same place, then you can run it as any user you want and it won't create a separate home dir.
t
@bdw429s So if I run sudo box after that properties file sets the commandbox home to ~, nothing CommandBox related will be but in /private/var/root?
b
That's a pretty broad statement to agree to, but I can tell you the CommandBox home will be looked for in the location you tell it to use šŸ™‚
t
@bdw429s Ok thanks
@bdw429s That link to the commandbox setup above states that for Homebrew installations of commandbox, it places the binaries in /usr/local/Cellar. My MacOS does not have that directory.
It appears from the brew --cellar cmd that it actually lives in /opt/homebrew/Cellar
Maybe the ortus docs should mention this.
@bdw429s I've placed the string
Copy code
commandbox_home=/Users/<my_user_name>/.CommandBox/
into the filepath:
Copy code
/opt/homebrew/Cellar/commandbox.properties
and then ran
Copy code
sudo box
but it does not recognize this file location. Here is the run transcript:
Copy code
Configuring CommandBox home: /var/root/.CommandBox (change with -CommandBox_home=/path/to/dir)
Library path: /private/var/root/.CommandBox/lib
Initializing libraries -- this will only happen once, and takes a few seconds...
...
Libraries initialized

   ______                                          ______
  / ____/___  ____ ___  ____ ___  ____ _____  ____/ / __ )____  _  __
 / /   / __ \/ __ `__ \/ __ `__ \/ __ `/ __ \/ __  / __  / __ \| |/_/
/ /___/ /_/ / / / / / / / / / / / /_/ / / / / /_/ / /_/ / /_/ />  <
\____/\____/_/ /_/ /_/_/ /_/ /_/\__,_/_/ /_/\__,_/_____/\____/_/|_| (R)  v5.5.1+00562

      You can open your servers's web administrator by clicking the tray icon

Welcome to CommandBox!
Notice it simply generates a new .CommandBox in /private/var/root. Why is CB ignoring the commandbox.properties file? it is in the same location as the "commandbox" binaries are located.
From what I can tell, when you run "sudo box" it ignore the commandbox.properties file. I moved the properties file to /opt/homebrew/Cellar/commandbox/5.5.1/bin/commandbox.properties since box is in that same folder. But it made no difference, running "sudo box" still created the default /var/root/.CommandBox So frustrating that the docs make no mention of any of this.
c
the commandbox.properties file must be in the same directory as the box binary. If the "Cellar" directory does not exist in your installation, then the properties file does not need to be there either
t
@chris-schmitz as explained above, Cellar directory is not where commandbox documentation says it is. I installed commandbox using homebrew and it placed it in /opt/homebrew/Cellar. When the directions for using the commandbox.properties file states it should be in the same directory as the binaries. I would interpret that to mean the binary file "box" which is located in /opt/homebrew/Cellar/commandbox/5.5.1/bin/box Therefore that is where i placed the properties file. But when I use sudo box to start, it creates a new .CommandBox directory in /var/root. It ignores the valid string I placed in the properties file.
BTW I also tried placing the properties file in /opt/homebrew/Cellar since "commandbox" is there, but that is technically not a binary, it is a directory containing a tree of files for commandbox install. But starting sudo box still creates a new .CommandBox dir in /var/root (I remove it each time after it is created since I don't want it there.)
c
sorry, I don't have a Mac, so I can't check if/how paths have changed. I just know that I have not heard of commandbox.properties being ignored before. Maybe @elpete can enlighten us? šŸ˜‰
btw the PR is going to be released today
b
@teaman I don't have a Mac, and all of the Homebrew bits have been community-contributed. If the docs need updated to reflect a newer version of brew, please send a pull request for whatever has changed.
Brew does some really weird stuff, they are all Ruby devs so I guess that explains a few things šŸ˜† Generally speaking I have no freaking clue how Brew works, nor do I really care. The
commandbox.properties
file needs to be in whatever folder the binary lives in. So, whatever the heck brew is doing-- you'll need to know what actual directory is being the process thinks it lives in.
Here's the (Java) code that decides what folder we look in
Copy code
private static String getJarDir(){
		String path = new File( LoaderCLIMain.class.getProtectionDomain()
				.getCodeSource().getLocation().getPath() ).getParent();
		// Decode things like spaces in folders which will be %20
		return URLDecoder.decode( path );
	}
Brew does a bunch of symlink nonsense which makes it confusing though
Actually, we can make this real easy.
CommandBox will tell you where it's looking for the properties file!
Just start it with the
-clidebug
flag and you'll get a bunch of extra debugging output
Copy code
box -clidebug
You'll be looking for this one
Copy code
log.debug( "Checking for properties file " + cliPropFile.getCanonicalPath() );
That will tell you right were it was looking for the file
@teaman
c
@teaman @elpete PR is merged
FYI ... I agreed with Brad that Ortus is going to take over the ForgeBox project... that way any updates and fixes will be much faster than in the past
t
@bdw429s Thanks for the -clidebug tip. That revealed the location for the commandbox.properties file: Once I located the file there, now it finds it and all I have to type to start commandbox is "sudo box". It then finds the properties file, uses my users folder .CommandBox location that now has the downgraded mySql Connector/J 8.0.22 for coldfusion. It rewrites the hosts file with the commandbox-hostupdater now. Thanks to @elpete @chris-schmitz too!
I will note that specifying commandbox_home=~/.CommandBox does not work on startup. It has to be /Users/(your user name)/.CommandBox (assuming that is where you located it. It doesn't like the "~" char.
b
Yeah, "~" is a bash/shell thing, your file system doesn't know it. So where was the dir the file needed to go? Do we need to update the docs?
t
@bdw429s Oh, sorry, I meant to put that up. This is the location it was expecting:
Copy code
/opt/homebrew/Cellar/commandbox/5.5.1/libexec/bin/commandbox.properties
Turns out there are two "box" files, rather confusing. One in commandbox/5.5.1/bin and the one just mentioned in libexec. Maybe you can explain the why. Seems one should be named differently so as not to confuse. I now notice the size of the file in commandbox/5.5.1/bin is small. The one in libexec/bin is much larger. But that shouldn't detract from my point about the smaller one should be named differently.
b
One is a shell script that sets the java home env var and then calls the "real" box binary
This is all homebrew's doing, I have nothing to do with it, lol
So, do the docs need updated?
t
I would say so.
b
If so, I need you to help update them. I don't use homebrew, don't really understand it, and don't really care about it, so I depend on the poor Mac souls out there to help update that info šŸ™‚
t
If not for this forum I would have had a hard time figuring this out.
b
You can click the little 'edit on github' link on that page and send a quick pull request right from github
t
I'm a super notice at using homebrew.
This is like the only thing I've installed with it.
I'm not sure if this location is unique to the MacOS I'm using (Monterey) so maybe older versions differ.
b
It's possible the docs were last updated back before we started using homebrew's libexec feature
t
Who proofs what others submit using that crowd-sourced documentation approach?
b
it is nice to help force the java version you want without having to change your global java_home env vars, but it does make it more complicated on disk
t
Huh?
b
Who proofs what others submit using that crowd-sourced documentation approach?
Ultimately, I do. But when it comes to something I know nothing about like homebrew, I usually just assume they know what they're talking about. We can ping another homebrew user to help if you'd like.
Huh?
What didn't make sense?
t
Your comment about java_home.
What does that have to do with this thread
b
everything
I'm talking about homebrews confusing lib exec file
The one that confused you so much
Just cat the stupid thing out
it's a shell script
that does that I said above
• sets the java home • runs the "real"
box
binary
t
oh ok
b
And i was explaining why it's handy
t
ahh
b
And acknowledging how it confuses you šŸ™‚
t
I'll take a stab at the documentation PR later. Then you can review it. I can only put in what I experienced, not necessarily what other MacOS versions will experience. Or those with a different version of homebrew.
b
If you're on the latest homebrew, I'll assume it's what it does now
t
Yes but others may not be on the latest.
b
Remember how much I care about homebrew in general? I care about those out-of-date homebrew users even less
šŸ™‚
t
I'm not sure that's even a thing. Maybe HB users are always on the latest.
b
I think it's fine to have information that pertains the latest homebrew version
If people are behind, they can take it upon themselves to find out how their version of HB works
t
Just wish the HB install of CB would put in that properties file for you and tell you where it is and have that setting set to the default location.
b
The CommandBox docs are the last place on planet earth that need to start accounting for every previous behavior of HB šŸ™‚
HB install of CB would put in that properties file for you
That's an interesting idea, but if I were to guess, it's probably not possible šŸ¤”
t
HB seems to be the preferred method to install CB so I would think you would care.
b
That's Ruby code
If you would like to read through the non-existent documentation for what goes in this file and find a way, I'm all ears.
so I would think you would care.
About Mac users on an outdated version of Brew who want to find answers for how their old version of brew works under the covers? Nope. The CommandBox docs is not the place for that information.
t
No I was just saying that what I add to documentation may not be helpful to all. But you are right, we can't be too concerned with those running outdated HB versions.
Who maintains that script you linked to on github?
b
HOnestly, the entire brew process is a pain in my ass. • it requires manual steps to release every version • I can't automate it • The brew devs are INCREDIBLY picky • They change their spec unannounced every few months • I have to fight with them over all the stupid changes they want me to make to the formula every few releases • it was contributed by someone as a convenience for mac users
My goal is think as little as possible about it and touch it as little as possible
But I welcome anyone who wants to help maintain it for me šŸ™‚
t
It states where the binaries are. That was one gripe I had with the Ortus install docs. It says to put the properties file next to the binary file. But then doesn't say where that is. That script states where.
b
Who maintains that script you linked to on github?
It was originally written by Jon Clausen when he added support for this (He's a Mac user) and I've updated it over the years based on the changes requested by the Brew team and their massive set of super pedantic test servers.
There is a copy of that file in the main brew repo which I have to manually send a pull request to every release. Then I have to wait for a human to merge it (after making whatever random changes they've decided to ask me to make that week)
t
Ok I now understand where you are coming from. In that case, I would think Ortus would provide their own installation tool that removes HB from the picture. But it sounds like you don't care too much for Mac users either. But perhaps I misread you.
b
It says to put the properties file next to the binary file. But then doesn't say where that is.
I get it, but the answer to that depends on your operating system and how you're calling box. Homebrew users are the only people who have to deal with this based on the crazy weird stuff HB does. For the rest of the universe, it's super simple.
Ortus would provide their own installation tool
We've talked about an installer, but this is a non-trivial task and gives us one more thing to maintain. I've always really like the fact that
box
is just a binary you can drop on your desktop and run without the need for any sort of complicated installation process.
We also have box on Chocolatley. which is like brew but for Windows, but literally no one uses it (or any sort of windows-based package manager) so I never get asked about it šŸ˜†
šŸ™‚ 1
t
As I recall I tried that for my first install attempt but ran into multiple issues I don't recall. So I backed out and tried the HB approach. It worked but for this issue with the properties.
b
If you had issues just running the binary, it was probably related to the default version of java on your machine
Sadly, the CF engines are INCREDIBLY slow to support new java versions so I can no longer just expect box to run any longer on whatever java is installed šŸ˜•
Lucee is a complete no-go on Java 16+
t
Let me just give my honest feedback on CB... Once you get it up and configured, it's a dream for CF developers. But getting it to that point is rather painful. So an Ortus installer would be really welcomed.
b
Good to know. Want to help build it? lol
t
No time for that now. Maybe when I retire.
b
I played with Bitrock I think it was, but it was so super complicated, it was going to take me a few weeks to dig in and figure it all out
Sadly, CommandBox dev is only a portion of what I get to do so I'm limited in hours I can spend on it and bigger projects tend to get pushed back in favor of getting smaller fixes out the door
t
Wouldn't a shell script be adequate for installation?
b
Techically we have that, but I don't know right off if it works on mac
Luis worked on that for a while
Let me see if I can find it...
t
Mac runs on *nix as you probably know so I would think it would work on Linux and Mac.
Windows would be left out. So sad.
b
That's a bold assumption šŸ˜‰
t
šŸ™‚
Could be
b
Here it is
Copy code
sh -c "$(curl -fsSL <https://commandbox.app/install.sh>)"
I tend to just use apt/yum on Linux (also a pain in the butt to maintain) but Luis made that script as another way
Here's the contents of the script
It basically just downloads the binary and unzips it for you
It appears to mostly assume... • you have
curl
installed • you have
unzip
installed • you want the binary in
/usr/local/bin
Which is probably somewhat sort of mostly ok to assume
It doesn't do anything with your java version though, so it will just pick up whatever
java_home
has
The main reason I've wanted an installer for Windows is actually just because it's such a pain to put a binary in your PATH without editing your env vars which is lame on Windows.
But even that assumes the user won't have 2 or more box versions running side-by-side, which is totally supported
t
It wouldn't be too hard to modify to offer choice of where to install since I prefer it in my users folder and not in the OS as that gets into the need for sudo to modify, etc.
b
since I prefer
ā˜ļø And that right there is why it's so hard to build a simpler installer. Everyone wants to do it differently! šŸ˜‰
t
Then support an arg on the commandline to specify where.
b
I want to say the source for that shell script is in a repo somewhere. I need to find where Luis put it...
Looks like we do support an arg for the version right now
t
Not seeing that. I see DESTINATION var is hardcoded.
Oops, I see you said version, not destination.
@bdw429s I just now entered a PR for the Ortus CommandBox documentation for installing it on MacOS using Homebrew. Hopefully I did that process correctly. It shows up as from cfcoder (that's me).
šŸ‘ 1