Installer changes / Lucee Product "Stuff"

As a result of a slack thread where @AdamCameron asks about log paths etc - a reply was to use a link in our documentation to place the WEB-INF folder somewhere else. It was also mentioned in the thread that the {approot} should probably never have been used as the location for the WEB-INF folder, obvious security issues etc…

Additionally in the Sys-Admin section of the documentation has information for manually configuring Lucee to use port 80 and other useful “stuff” - that most people now do as “manual” install tasks themselves.

  • Could/should - these things be part of the installer?
  • Is it a manpower / available hours in the day / priorities “thing” that stops them from being there?

And if so…
Especially with a major release, with possible breaking changes, now being actively worked on - is there an opportunity for;

Tell us the “little” things that really piss you off about Lucee - that you have a work-around for - that you think should be implemented into the product (with the details of the workaround/etc).

And more “pro-actively”;

Give us your changes, now, for active consideration;

and (hopefully) inclusion

Then of course the extra questions that come to my mind, thinking of these things, aloud is;

  • How do we make that happen?

I know I can “just” create a pull-request (PR). But is that it? Is the only thing stopping a bug-fix / feature inclusion a PR?

  • Do we need more committers / Do we need to trust some more people with “committer” rights?

In a previous thread I asked about submitting documentation changes and adding examples to the docs - (which I am doing some work on at the moment)…

But I also mentioned that I used to be the Patch manager for the Apache SVN project (for quite a few years) - and if it is helpful, at all - I’d happily do it again for the Lucee Project.

Where the Patch Manager is responsible for weekly emails (to a public forum) of the new patches that were submitted by non-committers in the past XXX (period) along with a list of all “unresolved” patches - so that nothing gets “lost” and people can comment on them, “+1 / -1” them: to show their view on the submission.

(Yes I know we have the issue tracker - but things sometimes do just go into the issue tracker to never, ever be seen again! - and that’s why, at least in Apache projects, they have this role)

The installer one, I mentioned earlier, “I” see as something almost anyone could help with - as it doesn’t need Java skills or an in-depth understanding of “Lucee” internals.

  • Edit the install scripts to also configure Tomcat’s XMLs for port 80
  • Install any required dependencies - which we have to do ourselves (following the current docs)

If you’re like me - you HATE having to repeat the same steps, manually, all the time. So you might create a script that does “that” for you, automatically - with a couple of tweaks - you’ve just implemented your change, permanently into the installer(s) for everyone’s benefit!

I suppose the BIG question is,

  1. What does the project need help with?

Do you have a list - where someone can say;

  • “I” can (ongoing) create / test / etc the .RPM install.
  • “I” can do xxxx - but will need a hand with yyyy
  1. Do you actually want help with it?
  2. Does it require some sort of “Lucee Association” input?

“I” can’t help with any “serious” Java programming - I only know enough to be dangerous…
But I sure can help with documentation / CFML coding / Creating installers / Lucee as a project, tasks…

And I sure bet I’m not the only one - who could volunteer to help with “a” part.

Thanks as always!
Gavin.

1 Like

I’m responsible for the all the installer stuff / build process for Lucee (amongst other things) and I’m totally open to improve all this. that would be an excellent starting point, I can share with you privately our license key for install builder, if you want to play.

For example, I’d love to have the build process for the installers automated via a github action (like we already have for docker and commandbox).

I love the idea about improving / automating all the annoying little things we do.

The standard process is to start a thread here on the the forum proposing the changes, we’ll discuss it here and once we have reached consensus that the change will be accepted, it’s time to develop and then submit a PR. At the end of the day, code speaks louder than words!

I’m also more a cfml dev than a java dev, so we have a bit of a roadblock in terms of code reviews for java changes at the moment.

Hi Zac,

Thanks for the reply.
Can you please share with me the installer license?
I will indeed have a “play”.

I’d like to start with providing a; “set the port, Lucee uses” as my learning exercise.

Gavin.
Thanks.

sent via DM!

here’s an open issue if you want to dive in

Not able to set the password while installing Lucee using silent installation steps in windows.
https://luceeserver.atlassian.net/browse/LDEV-3782

Awesome - thanks!

I have been looking at this for about 6 hours, now.
And I think I am dumber for the experience!
I have absolutely no idea how the password is used, even with the GUI installer - let alone the unattended mode.

As a guess there is a
HTTP POST action : http://127.0.0.1:${tomcatport}/lucee/admin/server.cfm

Which has query parameters, new_password and new_password_re defined.
Unsurprisingly, adding them to the URL after an unattended install - does not help.
I still get the No Password Set error.

Gavin.

HI everyone,
The issue here is;
If you chose to install the IIS Connector AND chose NOT to use the bundled JRE, the install would partially fail. A side-effect being that the password was not being copied from the installer into the server and web contexts XML configuration files.

The installer now works with all combinations of do/don’t install IIS Connector | Bundled JRE.

All details are in this PR

Gavin.