Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

www-servers/tomcat: add systemd support. #1358

Closed
wants to merge 10,000 commits into from

Conversation

@nE0sIghT
Copy link
Contributor

commented Apr 26, 2016

As part of systemd support multi instance feature reworked a bit:

  1. Instance manager dropped. OpenRC init script may be symlinked now.
  2. Instances are managed through config files in /etc/conf.d
  3. By default instances are located in /var/lib/tomcats folder as in RHEL
  4. Non named systemd unit provided and openrc init script may be started without instance symlink

I'm aware about systemd QA notices however /etc/conf.d is best place for configuration files in that case imho.

Bugs fixed:
https://bugs.gentoo.org/show_bug.cgi?id=485000
https://bugs.gentoo.org/show_bug.cgi?id=567892

@monsieurp

This comment has been minimized.

Copy link
Member

commented Apr 27, 2016

@chewi

This comment has been minimized.

Copy link
Member

commented Apr 27, 2016

This isn't any reflection on the work (I haven't looked at it yet) but just a note to @monsieurp and whoever to not merge this without me or @fordfrog okaying it first. We're both kinda busy.

@monsieurp

This comment has been minimized.

Copy link
Member

commented Apr 28, 2016

I was going to click the Merge pull request button but thanks for letting me know James. You just avoided a catastrophe.

@monsieurp

This comment has been minimized.

Copy link
Member

commented Jun 5, 2016

James, have you got round to reviewing this PR? My guess is you haven't. 😢

@chewi

This comment has been minimized.

Copy link
Member

commented Aug 11, 2016

I've skimmed through this now and I like the overall approach but there's some minor points that need addressing.

You shouldn't source /lib/gentoo/functions.sh into the context of the OpenRC init script. OpenRC has its own binary versions of these functions under /lib/rc/bin. See if there's a way to determine whether you're running under OpenRC or not to make this conditional. You also need to apply @GENTOO_PORTAGE_EPREFIX@ to the path.

This isn't your fault as the current version already does this but the other instances of @GENTOO_PORTAGE_EPREFIX@ are wrong. It has a leading slash, not a trailing slash. Change /@GENTOO_PORTAGE_EPREFIX@ to @GENTOO_PORTAGE_EPREFIX@/.

nE0sIghT added a commit to nE0sIghT/vortex-overlay that referenced this pull request Aug 15, 2016
nE0sIghT added a commit to nE0sIghT/vortex-overlay that referenced this pull request Aug 15, 2016
@nE0sIghT nE0sIghT force-pushed the nE0sIghT:feature/tomcat-systemd branch from 0d55f2e to 78566d5 Aug 15, 2016
@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented Aug 15, 2016

New commit pushed.

  1. Added check for RC_SVCNAME environment variable before including gentoo-functions
  2. Fixed GENTOO_PORTAGE_EPREFIX slashes.
  3. Fixed path to configuration file in error message
  4. Synced versions with main tree
@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented Sep 16, 2016

Ping

@chewi

This comment has been minimized.

Copy link
Member

commented Sep 16, 2016

We've actually been looking at this in conjunction with some other big tomcat changes. I was going to merge it the other day but I hadn't noticed that it does away with the instance manager. This is probably the way to go but it is a breaking change for end users and I want to make sure we get such a change right first time.

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented Sep 16, 2016

I see, thanks. Just say if I can help somehow

@fordfrog

This comment has been minimized.

Copy link

commented Sep 17, 2016

@chewi what are your concerns at this moment? yes, it breaks how tomcat is deployed but we already did that once when we introduced the manager. in my opinion we should introduce news item for this change so things do not stop to work accidentaly without the administrators/users noticing it. otherwise i think this is the right way to go with regard to multiple instances implementation.

@wltjr

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2016

Keep in mind tomcat does not work out of the box. If you emerge tomcat it will not start, there is no init script till it is created by the instance manager. Which creates it outside of portage and causes it to not be updated when the package init script is updated. Really can't make things worse than they are, I am for the change. I have always hated the instance manager, it was not done the gentoo way. This seems to be with symlinks to init script for instances, and env files for instances. 👍

@mgorny mgorny removed the bugfix label Dec 11, 2016
@orlitzky

This comment has been minimized.

Copy link
Contributor

commented May 10, 2017

I host a few tomcat websites but don't know much about the Java ecosystem generally. I would really appreciate a wiki page that tells me how to keep my existing sites running, and how to migrate them to the new init design.

@fordfrog

This comment has been minimized.

Copy link

commented May 18, 2017

@nE0sIghT do i get it right that with this new implementation i can run only one instance of each tomcat slot or i missed something?

@orlitzky

This comment has been minimized.

Copy link
Contributor

commented May 18, 2017

@fordfrog I believe this reverts to the "usual" way of running multiple instances of a service with OpenRC. Consider for example your network service: there's only one real script, /etc/init.d/net.lo, and then to create a network service for eth0, you create a symlink to /etc/init.d/net.lo called /etc/init.d/net.eth0. Inside the init script, the RC_SVCNAME variable is used to figure out which interface to actually bring up.

I haven't tried it, but I think the idea is the same here. To create a new instance, you would create a new symlink called /etc/init.d/<instance-name> and point it at the one tomcat init script. I'm not sure how the rest of the instance creation (config files, log files, etc.) would go.

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2017

@fordfrog
You can run any number of instances regardless of slot.

With systemd you just enable them using named unit.
With openrc you should create symlinks as @orlitzky said.

@fordfrog

This comment has been minimized.

Copy link

commented May 18, 2017

so generally, the following "two" directories are shared among all instances withing the same slot unless user modifies the paths, right?

(from tomcat-r1.conf)
CATALINA_TMPDIR="@GENTOO_PORTAGE_EPREFIX@/var/cache/tomcat-@slot@/temp"
#CATALINA_WORKDIR="@GENTOO_PORTAGE_EPREFIX@/var/cache/tomcat-@slot@/temp"

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2017

@fordfrog

That's right.

@orlitzky

This comment has been minimized.

Copy link
Contributor

commented May 20, 2017

I think sharing the work and temp directories by default should be avoided, if possible. Sharing /tmp has caused thousands of security vulnerabilities, and sharing the tomcat temp directory in particular goes against their recommendations. From https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html:

File permissions should also be suitably restricted. Taking the Tomcat instances at the ASF as an example (where auto-deployment is disabled and web applications are deployed as exploded directories), the standard configuration is to have all Tomcat files owned by root with group Tomcat and whilst owner has read/write privileges, group only has read and world has no permissions. The exceptions are the logs, temp and work directory that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they can't change the Tomcat configuration, deploy new web applications or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2017

@orlitzky

That's why it should be overriden for new instances.
Default value is for single instance only. We can describe this in wiki.

@orlitzky

This comment has been minimized.

Copy link
Contributor

commented May 20, 2017

@nE0sIghT is there a reason it can't be done for you? For example, instead of

CATALINA_TMPDIR="@GENTOO_PORTAGE_EPREFIX@/var/cache/tomcat-@slot@/temp"

you could have

CATALINA_TMPDIR="@GENTOO_PORTAGE_EPREFIX@/var/cache/@RC_SVCNAME@/temp"

Then, in the init script, you would replace the RC_SVCNAME placeholder with its value (that OpenRC provides). Prior to starting the daemon, checkpath could be used to ensure that the directory exists and has the correct permissions. I don't see where /var/cache/tomcat-@slot@/temp is being created... since directories under /var/cache can disappear, that checkpath may need to be added anyway, unless Tomcat creates the paths itself when it starts.

Unrelated: why /var/logs and not /var/log?

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2017

Then, in the init script, you would replace the RC_SVCNAME placeholder with its value

@GENTOO_PORTAGE_EPREFIX@ is replaced at install time.
$RC_SVCNAME is resolved in OpenRC init scripts only.
What are you suggest for systemd?

Did you tried to implement your suggestion?

Unrelated: why /var/logs and not /var/log?

It's typo. Thanks for notice.

@orlitzky

This comment has been minimized.

Copy link
Contributor

commented May 20, 2017

I don't use systemd, so I can't promise this will work, but it has some template variables as well:

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

You might be able to use %i or %n instead of $RC_SVCNAME.

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2017

@orlitzky
For what you suggest we should implement some replacement hack in init engines.
I do not think it's right way.

Just try to implement your suggestion with openrc.

DerDakon and others added 20 commits Feb 23, 2018
Package-Manager: Portage-2.3.19, Repoman-2.3.6
RepoMan-Options: --include-arches="sparc"
Package-Manager: Portage-2.3.19, Repoman-2.3.6
RepoMan-Options: --include-arches="sparc"
Package-Manager: Portage-2.3.19, Repoman-2.3.6
RepoMan-Options: --include-arches="sparc"
Closes: https://bugs.gentoo.org/643566
Closes: https://bugs.gentoo.org/627010
Closes: https://bugs.gentoo.org/639786
Package-Manager: Portage-2.3.19, Repoman-2.3.6
Package-Manager: Portage-2.3.19, Repoman-2.3.6
Package-Manager: Portage-2.3.19, Repoman-2.3.6
Package-Manager: Portage-2.3.19, Repoman-2.3.6
Package-Manager: Portage-2.3.19, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
RepoMan-Options: --ignore-arches
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Removed 2.29.0-r300 entry.
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Upstream major release, changes a few things including a x2goagent
wrapper script
Update ebuild accordingly
Replace some sed calls with patches in ebuild

Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
As part of systemd support multi instance feature reworked a bit:
1. Instance manager dropped. OpenRC init script may be symlinked now.
2. Instances are managed through config files in /etc/conf.d
3. By default instances are located in /var/lib/tomcats folder as in RHEL

Closes: https://bugs.gentoo.org/show_bug.cgi?id=485000
Closes: https://bugs.gentoo.org/show_bug.cgi?id=567892
@nE0sIghT nE0sIghT force-pushed the nE0sIghT:feature/tomcat-systemd branch from 336b861 to b56fde3 Feb 23, 2018
@gentoo-repo-qa-bot

This comment has been minimized.

Copy link
Collaborator

commented Feb 23, 2018

Pull request CI report

Report generated at: 2018-02-23 16:47 UTC
Newest commit scanned: b56fde3
Status: good

No issues found

@flappyports

This comment has been minimized.

Copy link
Contributor

commented May 20, 2018

ping

@nE0sIghT

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2018

I will rebase it to latest tomcat versions.

@chewi

This comment has been minimized.

Copy link
Member

commented May 20, 2018

Sorry, this isn't your fault but I'm going to be very blunt. If you want to see this merged, you're going to have to become a dev and take responsibility for it. @fordfrog evidently only has time to bump Tomcat when necessary and I'm not about to take this on because the fall out from users could be quite big. I'm half way out the door from the Java team with my own involvement being limited to JVMs these days and even that is something I have little personal interest in now. Beyond that, we only see sporadic contributions from one or two others. It sucks but that's just how it is.

@wltjr

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2018

@nE0sIghT if you become a dev you will need to take over dev-java as there are countless outdated packages. For example Tomcat 9.0.8 needs a newer ecj. Much less anything else like Java 10+ etc. Its a big undertaking. Just so you have a clue what your getting into. Also this needs considerable work to be added. I did some of the necessary work over a year ago. But likely needs more work. I just fixed it for my needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.