Hi Andre et al, I've dealt with a lot of different servers and OSes over the years, and my 'professional' advice to everyone maintaining a java/web application would be to create a root level directory and install everything they rely on there and maintain it themselves. This includes especially java, tomcat, databases (especially modern ones like mongo or crate), search engines etc. Leave the OS basics and security stuff to the OS maintainers and do everything else by yourself. With puppet, chef or ansible maintaining many servers is not a big issue anymore, and most hosting providers will have support for this or that automation technique. Or go straight for docker.
Just two weeks ago I had a pleasure of watching someone loosing his production site, cause auto-upgrade just screwed their crate.io installation. regards Leon P.S. I haven't used debian for 4-5 years now, but I know that back in the days they considered stuff stable after two years without major problems, which is past EOL for modern software. This approach is surely ok for things like routers or mail servers, but you don't want to stick to a two year old version of mongo or tomcat. On Wed, Aug 16, 2017 at 11:27 AM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > This being a Tomcat list, and Tomcat being java, it is rather to be > expected that many people on this list would tend to have a rather > Tomcat-specific, and rather Java-specific view of the world. And the fact > that most Linux distributions have their own way of packaging software, and > installing it according to their own logic, does not always make it easy > for others than the supplicant, to provide meaningful help. > > This being said, in the real world, Tomcat/Java applications often have to > share a host with many other applications/languages, and managing such > hosts is generally the task of sysadmins, who many times don't even get to > choose the OS of the host which they have to administer and keep running. > For these people, it is often impossible to manage each host and software > package individually, and they have to use tools appropriate for the job of > managing multiple hosts with multiple applications each. Some of these > tools are the corresponding platforms' "software package managers", working > from corresponding "software package repositories" containing (hopefully) > software packages in versions which have been previously tested to be > "production-ready", secure, AND not conflicting with other software > packages likely to be in use on the same hosts. > > These tools sometimes install bits and pieces of some packages, in places > which do not appear to the single-package specialist as being "natural". > But generally, they do make sense if one considers the whole host, its > multiplicity of packages, and administrative constraints (such as backups, > disk space allocation, logfiles management, security-related updates etc). > Independently of this, I for one also have corporate customers who have > their own rules, and won't let me install or configure some things in some > places of the filesystem, and insist on them being where their own rules > dictate (/opt, /var, /src, /srv, /mnt, you name it). > > So I believe that regular rantings on this list about this or that > distribution, and how it decides which version of the product it includes, > and where it actually installs the various parts, are in the end > time-consuming and rather counter-productive. > Because that is just the way the world is, and most of us cannot change it > easily. > > Mercifully, Tomcat is designed in such a way that it /can/ be installed > and run according to almost any architecture and layout. (As long as one > has access to its configuration files, which is also not always a given). > > On this list, I believe that we try to help anyone who has a problem with > Tomcat. > Sometimes we cannot do that, or can only do it uneasily, because the > problem may be due to a configuration or layout issue which we cannot > guess, or cannot reproduce. > /That/ is why we would sometimes /recommend/ to the supplicant to try to > install a "vanilla" version of Tomcat fom the Tomcat website, and check if > they can reproduce the issue there. But we cannot /force/ the supplicant > to do that, and sometimes they may not be able to do that for whatever > reason. > In such cases, we may sometimes be unable to help, but that also is the > real world, which requesters on a volunteer-manned help forum for a package > that is open-source and free, should also understand. > > P.S. Speaking professionally : we develop and run our applications on our > own servers (Linux, Debian) as well as on some customer servers (Debian, > RedHat, Suse, and even Windows). I do not remember why we initially chose > Debian as our main platform, but we now have some 40 servers with it. We > are "comfortable" with it (today as well as previously), we have no > particular problem with it, and it would be costly and time-consuming to > change to another main platform. Over time, we have learned how Debian (and > other platforms) install things and where, and we have documented it. Our > usage of Tomcat may be simple, but I cannot recall exactly how many years > ago we last had a Tomcat issue which had to do with how Debian installs it > on the disk. > Other people's mileage may vary, but I thought it was worth mentioning > this, to provide a balancing opinion. > > > > On 16.08.2017 09:24, Leon Rosenberg wrote: > >> Debian has a long tradition of doing things in a very special way when it >> comes to java. Long enough they shipped GnuJ as standard JVM with a debian >> distribution, a piece of garbage that wasn't able to start simplest of >> java >> programs. >> But there has been an as long tradition to reply to every question about >> tomcat behaviour on a specific distribution by suggesting to throw the >> crap >> away and download the vanilla tomcat form the one and only legal source >> ;-) >> (at least in the past, to which debian belongs). >> >> regards >> Leon >> >> On Wed, Aug 16, 2017 at 7:43 AM, Peter Kreuser <l...@kreuser.name> wrote: >> >> I'd assume the service that starts tomcat sets the bin-Dir, that contains >>> a setenv.sh, that has the CATALINA_HOME and BASE env-Varaibles, where you >>> find the context-Files that have a docbase. >>> >>> I'd like to repeat the question: who did this setup? >>> >>> Peter Kreuser >>> >>> Am 15.08.2017 um 23:45 schrieb James H. H. Lampert < >>>> >>> jam...@touchtonecorp.com>: >>> >>>> >>>> I think I've mentioned before that I have a Tomcat server on a Google >>>> >>> Compute Debian instance, that I installed with an "apt-get," rather than >>> from an Apache download. >>> >>>> >>>> I had to apt-get manager separately, which is odd to begin with. >>>> >>>> And things ended up in unexpected places. >>>> >>>> Some stuff (like the Catalina directory) wound up in /etc/tomcat7. Other >>>> >>> stuff (like the bin and lib directories) wound up in /usr/share/tomcat7. >>> >>>> >>>> But the weirdest thing is where the webapp contexts wound up. The >>>> >>> default ROOT context (which doesn't look quite like the default ROOT >>> context of anything I've installed from an Apache download) is in >>> /var/lib/tomcat7/webapps/ROOT. But the manager and host-manager webapps >>> are >>> in /usr/share/tomcat7-admin/manager and /usr/share/tomcat7-admin/host- >>> manager. >>> >>>> >>>> Setting aside any questions of why whoever set this up for Debian did it >>>> >>> this way, all of this still raises a very big question: >>> >>>> >>>> How is Tomcat finding all of this? >>>> >>>> -- >>>> JHHL >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
