There’s a number of things that could be at play, and without seeing your setup and knowing exactly everything you’ve run, from what directory, in what order it’s very hard to guess.
Things to check for:
Lucee needs to be restarted to pick up any changes made to its XML files by CFConfig
Check you don’t have more than one server started in the current directory with the server list and/or server list --local commands.
Make sure you’re running that command in the correct folder where the server lives. Should be the server details that show either in CommandBox Bullet Train or when you run server info in that folder.
that command, as you ran it, would only modify the server context of Lucee. Setting the web context password would require a slightly different command as documented here.
There wouldn’t be. The server.json file has nothing to do with where CFConfig stores settings. The change would have been made to the XML file inside the Lucee server home that stored the server context settings.
I’d start new threads for this stuff or this thread will just become unmanageable. Your error may be getting in the way of your password woes, but it’s sort of another issue entirely.
As to what he error means-- it basically says you tried to stop a server (which involves connecting on a “stop port” and shutting down the server process) but the stop port stored for this server wasn’t bound anywhere, so CommandBox isn’t really sure how to proceed. If you know the server is running, then it could be hung, or perhaps you’ve been switching back and forth between running commands as root and running commands as non-root users which will get things mixed up quite fast as every user you run CommandBox gets their own separate CommandBox home under their user directory which different settings, different servers, different config, etc, etc. If you’re mixing and matching users, I recommend “pinning” the CommandBox server home to a single folder shared by all users as documented here with the commandbox.properties.
I don’t understand what that means. What settings exactly couldn’t you change?
I have only one server. As mentioned in my post, I am running box from the Unix shell at /web/default/wwwroot which is my web root.
I’m clearly missing something here about the relationship between server.json, CFConfig, XML files for server setup, .CFConfig.json … I’ve seen a lot of these floating around and I’m not really understanding what the differences are between them, particularly in relation to how settings are set through CFConfig in the CommandBox shell. Maybe this will make more sense as I continue to problem solve?
I just completely rebooted my entire machine. Here’s an example of a set of commands I just ran:
ubuntu@ip :/web/default/wwwroot$ box
CommandBox:wwwroot> server list
Processing (1) servers, please wait...
wwwroot (stopped)
http://127.0.0.1:8080
CF Engine: lucee 5.4.3+2
Webroot: /web/default/wwwroot/
Last Started: 15-Dec-2023 21:20:10
CommandBox:wwwroot> server start
√ | Starting Server | √ | Setting Server Profile to [production] | √ | Loading CFConfig into server
CommandBox:wwwroot> server listProcessing (1) servers, please wait...wwwroot (running)
http://127.0.0.1:8080
CF Engine: lucee 5.4.3+2
Webroot: /web/default/wwwroot/
Last Started: 15-Dec-2023 22:15:20
CommandBox:wwwroot> cfconfig set adminPassword=mypassword
[adminPassword] set.
CommandBox:wwwroot> server restart
Trying to stop server...
> server stop 'wwwroot'
Stopping wwwroot...
Stopped
Trying to start server...
> server start name='wwwroot' openBrowser=false debug=false --!saveSettings
√ | Starting Server
| √ | Setting Server Profile to [production]
| √ | Loading CFConfig into server CommandBox:wwwroot>
When I now go to the server admin page, the password works, but when I enter, I get to a page that says, “Error - requested action does not exist” and when I click any other link in the administrator, I’m spit back out to the login page.
that command, as you ran it, would only modify the server context of Lucee. Setting the web context password would require a slightly different command as documented here.
I’m afraid there is nothing at that link about setting the web context password.
Just to clarify some things:
I have not and never will run CommandBox as root.
I have never run Commandbox anywhere but in the /web/default/wwwroot folder.
I am also using Nginx as a reverse proxy (as I learned from you yesterday that this is the only option available for serving port 80.)
I am attempting to access the admin pages externally through port 80 as I am on a GUIless server and can not administer them internally.
I also want to note that one of my chief concerns is what appears (to be clear, appears to me) to be the ephemeral nature of CommandBox server instances. Something that really scares me about CommandBox is that it seems like the server just sort of disappears forever when a server stop command comes through. So I worry a lot about how all the configurations are being saved permanently so that I don’t have to, say, set a new Web administrator password every time the Lucee server – or the Ubuntu machine – has to stop and restart. This is where I am really unclear on the CFConfig/.CFConfig.json/server.json point from earlier. Perhaps it would help to note that my end goal is a stable, public, production web server for just one website that runs as a service on Ubuntu that I leave alone and update only as needed?
server.json is the primary config file for CommandBox that sets up how the server starts, what ports, what CF engine, what web root, rewrites, lockdown, etc
CFConfig is a CommandBox module that helps you set the actual CF configuration that you see in the Lucee or Adobe CF web admin such as datasources or mail servers.
The XML files are files stored inside the Lucee or Adobe server home where they store settings such as datasources or mail servers.
.cfconfig.json is a file that if found by convention, will automatically get imported when starting a server. This allows you to configure things like datasources or mail servers in that JSON file and the first time you ever run server start all the config is just pulled into the CF administrator and ready to go without needing to manually configure anything.
So, it sounds like this thread is done, and a new thread should be started for any new questions/issues?
This is a known bug in Lucee, completely unrelated to anything else being discussed. https://luceeserver.atlassian.net/browse/LDEV-4675
It was fixed in Lucee version 5.4.3.4 but for some reason you chose an older Lucee version (5.4.3.2) so you don’t have the fix. I would recommend you upgrade Lucee.
I never said there would be. I said there would be information in that link about modifying settings in the Lucee web context. The docs aren’t going to contain every single possible command that can ever be run on every server ever for every setting ever. You’ve got to piece some of this stuff to together. What there are docs for are:
how to set a setting (in general)
all the setting names you can set
how to make a command target the Lucee web context
It’s up to you to piece these together to find the command you need to run today on your server for your needs.
That missed my point. Forget about root. If you run CommandBox as different users regardless of what those users are called my statement will apply to you. So if you start a server as the bob user and try to stop it as the tom user, you will have issues.
This is not true. We’ve told you that a simple port forwarding is also available and the most recommended approach I’ve seen when I google this issue in general.
That’s not the case and I’m not sure what would make you say that. Even though, you’ve stopped a server
the Lucee server home (and its config files) still live under the CommandBox home dir
the server and it’s settings should still be visible in any of the commands such as server list and server info
The server home and it’s XML config files will not be deleted unless you run the server forget command and answer “yes” to the “are you sure” prompt.
Other than the actual server process stopping and releasing its ports, are you seeing something else “disappearing”?
All Lucee settings will survive both a CommandBox server restart and an operating system reboot.
Now, that said-- CommandBox IS designed for the servers themselves to be something don’t have to worry about going away. One of the goals is you CAN “forget” a server at anytime and a simple “server start” will bring everything right back and ready to go. That is why we have the config files such as servrer.json and .cfconfig.json to store all your settings so it can all be loaded back in and setup with zero effort.
@GoOutside I have an Ubuntu server I just launched from scratch with NGINX + CommandBox running and can show you what I did. That may help clear up some things. If you have Zoom and want to jump on for 15-20 minutes, let me know. I’ll be online for about another hour. I sent you a DM with the link. And if not, no problem.
I can’t update the version until I get into the server admin page. Unless – and this is where I’m still trying to learn about CFConfig – there’s a way to do it in CFConfig? I searched the CFConfig documents for “version” and found nothing about how to set the Lucee server version. (There seems to be stuff about the version of CFConfig?) Look, I’m not trying to be a jerk here, honestly, I just don’t know how this stuff works. I really want to use it! I’m not seeing any examples of how to use it, the examples are just so, so, so, so, so important to me.
That’s not the case and I’m not sure what would make you say that.
I maybe should be more clear that it only seems like the server disappears because, for me, a Lucee user who has had a traditional lucee/nginx server setup for many, many years, the way that CommandBox just sort of starts and stops servers seems very weird and hard to understand. To me, CommandBox looks like another Unix shell that just sort of sits over the top of an existing Unix shell and runs as a server. It feels weird. The server seems very attached to this shell, and the shell can go away, and when I look for evidence of the server, like a configuration file or something, it’s really quite hard to see where that is, permanently. This isn’t a criticism of your design, it’s just deeply confusing to me because I’ve never encountered it before and it’s hard to understand (and there is almost nothing available out there to help me understand it).
Also, again, to clarify, I am not running CommandBox as anything but the only user that I have access to running things on this Unix shell as: ubuntu. So, it’s always and forever just one user: ubuntu.
server.json is the primary config file for CommandBox that sets up how the server starts, what ports, what CF engine, what web root, rewrites, lockdown, etc
The XML files are files stored inside the Lucee or Adobe server home where they store settings such as datasources or mail servers.
That is why we have the config files such as servrer.json and .cfconfig.json to store all your settings so it can all be loaded back in and setup with zero effort.
.cfconfig.json is a file that if found by convention, will automatically get imported when starting a server. This allows you to configure things like datasources or mail servers in that JSON file and the first time you ever run server start all the config is just pulled into the CF administrator and ready to go without needing to manually configure anything.
OK, again, mega-mega confused here. I hope you are not going to be angry at me if I say that this all sounds like you’re telling me they all do the same thing. If server.json sets up the server, and .cfconfig.json sets up the server, what’s the difference? Which ones do CFConfig alter? Both? Do I need to alter them in order for things like Datasources and Web roots to be permanent when CommandBox restarts? But I thought CFConfig altered the XML files, instead? Now there’s two different JSON files that alter the XML? You don’t have to answer all of these individually, I’m just writing them because they’re indicative of the sort of questions I’m trying to go through in understanding how I can use these really amazing tools in a way that is lasting and makes the most sense.
If, for example, I want to have a server and web administration password set, do I set that in both the server.json and the .CFConfig.json? Or just once through CFConfig in the Box shell? What about datasources and logging details?
Just some really, realllllllly basic examples of how to use CFConfig to change settings like this would just be enormously useful. I know you have all put a huge amount of time into your documentation, and I am sure it is deeply insightful to people who know how to use the software, but I don’t, and that’s where none of it really seems to make sense to me.
server start name='wwwroot' cfengine=lucee@5.4.4.38 openBrowser=false debug=false --!saveSettings
Also, why are you using ‘–!saveSettings’? If you remove that from your command, all of these settings you are passing will be saved to a server.json file and used anytime going forward when you start/stop the server.
I"m not using !-saveSettings? I … don’t know how or why that would be showing up? When I run “box” from /web/default/wwwroot/ – I’m not sure why that shows up? I never added it.
Oh, I think the restart automatically adds it to ensure that no configuration changes happen on restart. If you run this, you should get the result you want.
server start name='wwwroot' cfengine=lucee@5.4.4.38
Will future restarts always automatically add that? How can I check to see if it’s enabled? This may have something to do with what I was saying earlier about how ephemeral and transitory CommandBox can feel.
By the way, I’ve tried using the material in this blog post as a guide for how to add a password to both the server and web administrators, since it is literally the only straightforward guide on how to do this that I could find on the internet.
I guess, suffice to say, it doesn’t work. These instructions set the server password, but not the web password.
@GoOutside Yes, but doing server restart isn’t going to cause any issues. And it isn’t going to make the server disappear - nothing like that at all. CommandBox is doing some awesome stuff for you that you might not be aware of yet.
When you run commands like these…
server start cfengine=lucee@be
CommandBox will store those values in a server.json. It looks like this:
Now here’s the cool part - everytime you stop/start or restart your server, before CommandBox launches your CFML engine, it checks for a server.json configuration file and if it exists, it uses it to start the CFML engine. Think of this as happening a layer above where CFCONFIG comes in. Things like port settings, Lucee version, disabling directoryBrowsing, security, and more are configured in server.json - and CommandBox is managing that file for you automatically - although you can easily edit the file yourself also.
The next layer is CFCONFIG. CFCONFIG is where you can configure specifics about the CFML engine: datasources, requestTimeout, etc. When using CFCONFIG, you can save the configuration to a JSON file, and CommandBox will automatically apply what you’ve set in ./cfconfig.json to your server.
Let’s talk about the next layer - environment variables. Did you notice them above in .cfconfig.json?
.cfconfig.json
"adminPassword":"${ADMIN_PASSWORD}",
CommandBox will check to see if you’ve defined environment variables in a .env file. If you have, it will load those when it’s configuring your server with CFCONFIG, and it will load them into Lucee also.
So I can create a .env file to set my Lucee admin password.
.env
ADMIN_PASSWORD=secret
The point is that CommandBox is abstracting a lot of the difficult stuff that we use to deal with in the past with traditional hosting, and it’s making it much easier to manage your servers - both in configuring them and running them.
And that doesn’t cover all the other stuff CommandBox does.
If you are new to these concepts, it can take time to get used to them but once you do, I think you’ll find them to greatly simplify your server environments.
When using CommandBox, you don’t need to update the CF engine the old way again. You just tell CommandBox what engine version you want and it gets it for you.
server start cfengine=lucee@5.4.4
The engine version does not go in CFConfig. It goes in the server.json. Really, these are basic things covered in the docs. I would really recommend you step back and read through the “embedded server” sections of https://commandbox.ortusbooks.com/ and the CFconfig docs: https://cfconfig.ortusbooks.com/ and then see if things are making more sense.
All the things a server.json sets are documented here:
and all the things CFConfig canset are documented here:
Just a brief review of the documentation would have made this clear.
If it’s any consolation, the way CommandBox starts and stops a server is right on par with how CLI tools for other languages like PHP or Node would work. It’s not a monolithic single web server you install. It’s a tool that can start as many servers in as may directories running as many versions of CF as you like and they can all be managed independently.
That’s the interactive shell. It’s not a requirement to use Commandbox, it just makes things easier, especially for Windows users who don’t have bash.
That would be incorrect. A server is attached to the shell that started it as much as a milkshake is attached to the McDonalds drive through window. Which is to say, not at all. When you start a server with the server start command, whether you use the interactive shell or not, simply fires off a Java process that runs on your machine. This java server process is a separate Java process from the CLI itself and stays running regardless of what you do with the CLI process (such as exiting).
I’m not sure what would give you that impression as I said nothing of the sort. I even gave examples of the things each file controls.
Do “ports, CF engine, web root, and rewrites” sound the same as “datasources and mail servers”? I would hope not as those are different words that mean different things.
That’s not at all what I said. I’m not even sure where you’d get that idea from. A “server” involves a lot of moving parts. Each file controls a different aspect of the server as I explained. Adding a datasource connection to your data base is part of the “server” but a very different part than setting what port is bound to. Not even Adobe CF or Lucee configure those two things in the same place.
Again, a precursory review of the docs should be answering basic questions like this. I’ve already answered this in this very thread even. I want to help you here, but you’ve got to help us help you
Yes, if you put your datasources in your cfconfig.json file, then they will be loaded into the server every time it starts, which means
first start ever
update to new version
after you forget the server
you always have all your config ready to go. One of the easiest ways to setup that JSON file is to add your settings manually to the CF admin and then export them to the JSON like so
cfconfig export .cfconfig.json
CFConfig is a powerful tool and can do a lot of things. Primarily it moves configuration from point A to point B where any point can be
a JSON file
a CommandBox server’s server home
ANY CF server home even installed on Tomcat
So when you import a JSON file to a server, the settings are read from that JSON file stored in the XML files for that CF engine (Lucee/adobe). When you run a cfconfig set command, that one single setting is written to the XML files for that engine. if you export settings like I showed above, the settings are read FROM the engine’s XML files and written to a JSON file. There’s like a million ways you can use it so there’s many ways it can fit into a workflow.
CFConfig handles CF engine passwords. But there’s not just “one way” you can do it. You can
do a one time set with cfconfig set
do a manual import from a JSON file containing the password
put a .cfconfig.json file with that exact name in the web root and it will get picked up automatically when you start the server
set a cfconfig_adminPassword environment variable which will get picked up automatically when you start the server.
These all do a similar thing and the end of the day and you can pick which one meets your needs.
CFConfig. See the docs I linked above that show what CFConfig handles. Just running
cfconfig show
will show you a JSON representation of all the Coldfusion settings CFConfig “sees” in your server’s XML files.
This is not a valid command. You’re mixing what CFConfig does and what the server.json does. Again, please spend some more time in the docs. It covers all these use cases with examples.
server.json contains the parameters by which CommandBox will start up the Lucee server, like Lucee version, heap sizes (my nemesis) etc.
.CFConfig.json is what CommandBox will use to set the Lucee things that can be set within the web and server administrator pages … I think? Do I need to be exporting and saving this every time I make a change? Is it being saved somewhere else, instead?
Your item about the .env for the password is really confusing to me, however.
Would it be too much to just ask: in a straightforward way, how do I set the Web and Server Administrator passwords with CommandBox? Does it have to be with this .env method? Can’t it be done with CFConfig? What do I need to do to make those passwords “sticky” so they’re retained in future server restarts? I’m sorry, this is really just kind of at the core of where I’m having a lot of set-up trouble, here. It’s a very “blocking” issue and I feel like we’re dancing around it but not just really directly addressing it.
Unless, of course, the method you just gave above is sort of how to do it? But that also isn’t quite clear to me, tangibly. Would I need to export the .CFConfig.json, then open it and manually add this environmental variable, then close it and save it in the webroot, and then make the .env file? Would that also go in the webroot? Also: I really super do not like the idea of storing raw passwords in the webroot? That seems weird? Or is it not?
Again, lots of dancing around, and I know we keep wanting to point to the documentation, but I’m sorry: it’s just not there. I’m sure if I understood the documentation and the interaction of CFConfig and CommandBox better I might be able to derive the method, but I’m not there yet. Right now, there is no straightforward, clear tutorial on setting the web and server administrator passwords.
As you can probably guess, I am not a professional developer. I have no training in any coding language, ever; literally everything I know about CFML comes from self-teaching over the internet for the last 20+ years. I don’t know what PHP and Node are, so that’s where I really struggle. I’m sorry. I am sure it’s frustrating. Nobody is more frustrated than me. CFML isn’t my job, it’s my hobby. It’s an outlet of creative expression and writing my stupid little web app might seem dumb and trivial for most people but it means a great deal to me. I know CFML is niche. I know what a bad situation this is for me. I don’t care to learn about Node, and that doesn’t mean your program is stupid or I’m dumb or anything. I’m just saying this to level-set on what my capabilities and understanding are.
I am asking questions and I can clearly sense your exasperation about them, but frankly I have done a “quick review” of the documentation. It’s actually been more than quick. I’ve spent a lot of time in them and – this is the thing – I don’t understand them because that’s not how I’ve learned CFML over the years. You’re speaking to me like I am exhibiting intentional negligence and hostility to your work. Honestly, it’s because I don’t and can’t understand your work. Many times I don’t understand what you or your documentation are saying. I am trying to understand! But the way you talk about these things as though they are “common sense” and it can be solved if you “just read the docs” … there’s a disconnect, here.
Look, I get that this is a barrier somewhat unique to me and my circumstances. I am trying to do the best I can in this world, trying to speak to my frustrations and questions in a way that is best understandable to people who actually are smart and talented and who make this their careers and passions.
But I am a hobbyist. My ability to do anything lives and dies by the simplest possible explanations that I can find on the internet and understand. For some people, that’s how they learn.
I have only been able to code in CFML for 20+ years because of the generosity and helping spirit of people who were willing to put up with dumb, uneducated amateurs like me, who asks weird dumb questions that don’t make sense. I wish I could help others the same way. But all of us have teachers, and few of us learn from reading a book alone. We all need teachers, at some point. I appreciate you all being teachers.
So, I appreciate the help. I really do. Genuinely. Seriously. I’ve relied on help my entire code-hobby life. But could we please lay off the insinuation that I’m just trying to tick everybody off, here? I’m trying my best.
Yes, if you want that setting to always be present. Nothing requires you to use CFConfig with CommandBox servers, it’s just very very useful.
Well, when you save a datasource in the actual Lucee web admin UI, it’s saved to the XML files in the Lucee server home, but those go away if you forget the server or change server versions. That’s why we recommend using a tool like CFConfig to manage all of those outside the Lucee server admin so you don’t have to worry about what happens when a server disappears because you have all the building blocks in your config files to create the same server from scratch with a single start command. This is the same reason CommandBox is so useful for a team of developers running code locally, because every dev on the team gets the exact same server instantly by just cloning the Git repo and running “server start” and letting the config JSON files do their thing.
Then forget about env for now. It’s useful but another thing for you to learn. Just get familiar with how the servers work and then come back and start a new thread to ask about env.
We’ve given you about 5 different ways to do it in this thread? Are you asking for more ways to do it, or do you have a specific question about one of the several ways we’ve shown you?
CFConfig finds and uses environment variables whose names follow a special convention automatically. So any env var named cfconfig_something will automatically get picked up by CFConfdig when the server starts and will set the “something” setting into the server. So using .env isn’t an alternative to using CFConfig. It’s just one of the may ways you can get CFConfig to load settings for you. All the .env file does is load up ad-hoc environment variables into the server process for you which is commonplace in Docker and other cloud hosting setups.
Nothing, really. Once a password is written to Lucee’s XML files, it’s there forever. Now, if you change what version of Lucee you want CommandBox to start, it will download and extract it to a new server home with different XML files. This is where having it in the JSON or an env var will ensure it gets set every time.
I assume you’re asking about the ${blah} placeholders. Honestly, would have waited to drop that wrinkle on you since you’re having so much trouble with the basics, but those place holders are simply swapped out when CFConfig reads the JSON file with any env var of the same name. So, if you declare
myEnvVar=brad
in your .env file and you have a ${myEnvVar} placeholder in a JSON file, those get merged when the file is read.
You’re not wrong. CommandBox allows you to configure any or all of these files to be outside the web root. But again, I haven’t mentioned that because you’re already complaining about all the basic information not making sense I’m trying to not overload you. It’s worth noting the CommandBox web server will BLOCK all access to files starting with a dot as well as all the known JSON config files. However, if you put another proxy in front of CommandBox, all bets are off as Nginx may happily serve up your .cfconfig.json file to a user if they look for it, so that’s something you have to take into account. here’s docs on the lockdown rules:
I’m not sure why you’re still balking about this. You were able to set the admin password like 6 messages ago and log in. Why are you still saying it’s an issue? You can find answers for this
OK, let me just be really clear and really, really straightforward, then:
What is the CFConfig command that will set the server and web administrator passwords, permanently, for a Lucee server instance in CommandBox (lasting through machine restarts)?
I have been able to set the server administrator password with
cfconfig set adminPassword=mypassword
That does not work for the web administrator.
We’ve danced around this. I don’t know what it is. Can we please just say what it is. It’s almost 5 p.m. on a Friday.
I don’t think you’re being malicious at all, and I’m happy to help you. You also aren’t making it very easy to help either. We all get it can be frustrating, but focus on what parts you need explained. You’ve made your point about 100 times now that you find it confusing. Repeating that point every post isn’t going to help. Grant offered to hop on Zoom with you earlier and provide you with free in-person support. I would have taken him up on that if I were you.
cfconfig set adminPassword=myPassword toFormat=luceeWeb
It’s also worth noting that when CFConfig picks up a JSON file or an env var on server startup for an admin password, it will also set that password automatically into your web admin if there has not been one set there. This is to prevent your webadmin getting left in an insecure state.
Thank you. That was all I needed. Note that there are five (5) references to “toFormat=luceeWeb” on Google. Just five. All of them refer to importing .json files into the configuration.
That’s why I was struggling.
This was hard – not easy – to find.
Thank you for your help and patience. I’ll continue forward with configuration and see what I can do and learn. My next steps are setting up datasources and then seeing how the server functions in this new environment. Wish me luck.
Do “ports, CF engine, web root, and rewrites” sound the same as “datasources and mail servers”? I would hope not as those are different words that mean different things.