Jason, I will fix point 2.
About 1., I have seen those classloaders directories being used by some
applications, in particular Alfresco from Ubuntu partner repository, so
changing this may break existing stuff.
About 3. I will have a look, but I'm not sure if I can make it work and
test it properly.
Forwarding your comments to the mailing lists for broader comments and
maybe help.
Ludovic
-------- Message original --------
De: Jason Brittain <jason.brittain@mulesource.com>
Sujet: Re: Tomcat packaging improvements
Pour :: Thierry Carrez <thierry.carrez@ubuntu.com>
Copie à :: Ludovic Claude <ludovic.claude54@googlemail.com>, Torsten
Werner <mail.twerner@googlemail.com>, Niels Thykier <niels@thykier.net>
This all sounds good to me. Out of the box, Tomcat is pretty
secure. Tomcat itself doesn't need the security manager enabled
in order to operate securely -- user's webapps might, but Tomcat
doesn't know which ones those are. A person has to make that
judgement. I tend to tell users that they should assume that the
webapps their company writes are insecure, but that malicious
successful exploits are rare, and that it tends to be very
difficult to exploit servlet webapps. Most developers and ops
Tomcat users sleep just fine at night knowing that their webapp
is available on the public Internet, and the security manager is
not enabled.
Torsten: Your idea to use debconf to decide whether Tomcat starts
automatically sounds like the best solution. Thanks.
Ludovic: I had a look at the docs you added, and they look great.
I had a few more topics I wanted to ask you guys about. These
are things that do not need to change for Lucid, if we don't have
time, or if we don't want to. I just wanted to bring them up to
discuss:
1. I noticed that the way we have tomcat6 configured is to add
back the classloader directories that were present in Tomcat
versions 4 and 5: shared/, common/, and server/. Stock Tomcat
6 got rid of these as of 6.0.0. Some software is still
written for Tomcat 5.5, and docs may still refer to these
classloading dirs.. I always found them helpful, since
Tomcat's classloader hierarchy still has these three
classloaders (server, common, and shared), but by default
Tomcat 6 was always configured to just load everything from
CATALINA_BASE/lib/. Being informed about Tomcat, I can handle
these dirs being present, but this will likely confuse some
users because stock Tomcat 6 doesn't have them. Looking
forward to Tomcat 7, they're not being reintroduced, either.
What do you think about eliminating these directories to make
the Debian tomcat6 package more like stock Tomcat 6?
2. One question about the Maven poms: If quilt pulls Tomcat
source from Subversion, and if Tomcat 6 source comes with
Maven poms (see res/maven/), then why does the Debian source
tree also include Tomcat poms? Am I missing something? I
have looked at what the diffs may be, and I didn't find
anything.
3. When the init script invoked Tomcat via jsvc, it had to be run
by an administrator user because jsvc itself had to be started
as root in order to allow binding to privileged ports. Now
that we use authbind, it doesn't require the init script to
run as an administrator to do the same thing. For example the
init script could run as user 'tomcat6' and starts, stops, and
restarts could work just fine while Tomcat could still bind to
privileged ports. So, what's the use case for the init script
being run as user 'tomcat6'? There are situations where the
administrator does not want to or cannot configure sudo for a
user to be able to run the Tomcat init script, or where there
is a script that runs as user tomcat6 that needs to be able to
either restart Tomcat or get Tomcat's status. It is possible
to make this work now that the init script doesn't use jsvc,
and I thought I'd ask you whether you think it would be
helpful to allow it. The code change would be only inside the
init script -- it would be a relatively small change to remove
the few lines of code that requires the user be root to run
it, possibly invoke start-stop-daemon without the --user
switch, maybe a small number of changes to make sure that
running the rest of the init script as non-root works
properly. I think the changes are pretty small. It would,
however, need to be tested afterwards to make sure the usual
use case works properly still. So, I'm not proposing making
this change for Lucid, unless there's time in the schedule to
test and debug it afterwards. What do you guys think?
Thanks.
--
Jason
On Thu, Feb 11, 2010 at 2:15 AM, Thierry Carrez
<thierry.carrez@ubuntu.com <mailto:thierry.carrez@ubuntu.com>> wrote:
Ludovic Claude wrote:
> I have committed the additional documentation, if nobody objects
to the
> changes or find any issue in the package then I will release it this
> week-end.
I had a look at the diff, and it looks very reasonable to me.
Minor remark about the README:
> * Tomcat is NOT secured by default. Before exposing your Tomcat
> instance to the internet, please change the passwords in
> /etc/tomcat6/tomcat-users.xml and turn on Java security: edit your
> /etc/default/tomcat6 file and set TOMCAT6_SECURITY="yes".
> After you may need to change the policy files in
> /etc/tomcat6/policy.d/
This sounds slightly too worrying to me. Especially since
tomcat-users.xml is secure by default (user/roles/passwords are
commented, so no user is defined !). I'd suggest changing this to:
* Tomcat is not running under a Java security manager by default. If you
expose your Tomcat instance to the internet, please consider editing
your /etc/default/tomcat6 file and set TOMCAT6_SECURITY="yes", then
adjust policy files in /etc/tomcat6/policy.d/ as explained in
http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html
Uploading over the week-end is perfect, I'll be able to make sure it
syncs in Ubuntu before Lucid FeatureFreeze (next Thursday).
--
Thierry Carrez
Ubuntu server team
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
02-12-2010, 08:08 PM
Mike Cloaked
Wolfgang S. Rupprecht-11 wrote:
>
>
> It isn't that serious of a situation. One can just comment out the
> offending line in /etc/named.conf and named will startup. The file
> /var/log/messages will have the pathname of the include that is no
> longer there and a quick scan of /etc/named.conf file show where it it
> included from. It is pain in the neck, but not a fatal catch-22.
>
>
One thing worth noting is that for some systems running f11 then, depending
on the history of the operating system, there may be incorrect includes at
the bottom of named.conf - occasionally there may be an additional (false)
reference to include "/etc/pki/dnssec-keys/dlv/dlv.isc.org.conf";
If you find multiple lines around lines like that maybe one is incorrect and
should not be there. I think you can take all the lines for the includes to
/etc/named.dnssec.keys as well and then restart named.
--
View this message in context: http://n3.nabble.com/Fwd-Notice-dnssec-conf-updates-in-Fedora-11-and-12-tp198226p204100.html
Sent from the Fedora Users mailing list archive at Nabble.com.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
02-16-2010, 10:08 AM
steve
Hi,
On 02/16/2010 02:58 PM, Alan Cox wrote:
>> (1) Curious about why you say Moblin is dead? I missed the announcement!
>>
>> (2) I'm writing this on a EeePC 1000HA (1GB, 160GB - but I'm using less
>> than 20G) running F12 very nicely.
>
> Moblin and Maemo are merging to produce one project using the best bits
> of each to produce a single distro
>
> www.meego.com
>
Sorry for hijacking the thread but I wanted to point something out to the fedora
folk out here who have not yet heard this -- MeeGo intends to use rpm instead of
deb for package management (yay !).
However, there's been a considerable amount of community bashing taking place
out on the MeeGo mailing list by current Maemo community members who are partial
to dpkg. A lot of the reasoning goes like this ....
...rpm has dependency issues ...
...rpm is slower than dpkg ...
...dpkg is more capable/stable/flexible than rpm ...
Now, the reason I bring this up here is, I assume most people here have come to
rely on and love yum (which is more like the front-end to something that, IMHO,
most users don't use these days -- rpm). As a package management system, I think
rpm is just as capable (if not more) than dpkg. However, the discussion on MeeGo
is turning out to be very biased, with even an active dpkg maintainer chiming in
with an offer to help (professionally too !) work out any possible issues
related to adopting dpkg[1].
As someone who would love to work on MeeGo without having to try various
hacks[2] to get a dev setup on a Fedora box, and also someone who would like to
simply bring some balance in the conversation I mentioned, I request people with
more rpm knowledge than mine to join the MeeGo list and participate in the thread.
Although it might have worked when that ^^^^ post was written, the present
installer script of the maemo sdk is broken on fedora because it first checks
for apt, and if that fails, just works with .tgz archives but still makes a lot
of assumptions about the install environment:
--
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 01:24 PM
inode0
On Tue, Feb 16, 2010 at 5:08 AM, steve <steve@lonetwin.net> wrote:
> Hi,
>
> On 02/16/2010 02:58 PM, Alan Cox wrote:
>>> *(1) Curious about why you say Moblin is dead? I missed the announcement!
>>>
>>> *(2) I'm writing this on a EeePC 1000HA (1GB, 160GB - but I'm using less
>>> *than 20G) running F12 very nicely.
>>
>> Moblin and Maemo are merging to produce one project using the best bits
>> of each to produce a single distro
>>
>> * * * www.meego.com
>>
> Sorry for hijacking the thread but I wanted to point something out to the fedora
> folk out here who have not yet heard this -- MeeGo intends to use rpm instead of
> deb for package management (yay !).
If after developing for your favorite open source project for years
the company "sponsoring" that project decided tomorrow that it was
merging with another project and you would need to switch to a
different packaging system I suspect your reaction would be different.
> However, there's been a considerable amount of community bashing taking place
> out on the MeeGo mailing list by current Maemo community members who are partial
> to dpkg. A lot of the reasoning goes like this ....
>
> ...rpm has dependency issues ...
> ...rpm is slower than dpkg ...
> ...dpkg is more capable/stable/flexible than rpm ...
While it is true that there is a fair number of silly arguments about
the technical merits of the change, the real problem is that there was
no transparency in the decision process leading to the change. There
was no explanation that I have seen even stating clearly why the
change is being made. I'm guessing it is related to LSB issues and the
decision to have The Linux Foundation direct the project.
Rather than adopting Fedora's package management system what Nokia has
needed from the very beginning of maemo was to adopt Fedora's
community model.
Even if this merger somehow turns out well for its target audience I
think it is a very sad display of the mismanagement of an open source
project.
John
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 02:37 PM
Michael Cronenworth
inode0 wrote:
> If after developing for your favorite open source project for years
> the company "sponsoring" that project decided tomorrow that it was
> merging with another project and you would need to switch to a
> different packaging system I suspect your reaction would be different.
Grown men, some of which have been Debian users/developers since its
inception, are bickering over this non-issue. It's a very fun thread to
follow on how not to handle a serious situation.
> While it is true that there is a fair number of silly arguments about
> the technical merits of the change, the real problem is that there was
> no transparency in the decision process leading to the change. There
> was no explanation that I have seen even stating clearly why the
> change is being made. I'm guessing it is related to LSB issues and the
> decision to have The Linux Foundation direct the project.
It's been explained. The Moblin part of the merger is being used over
the Maemo part. Simple as that.
>
> Rather than adopting Fedora's package management system what Nokia has
> needed from the very beginning of maemo was to adopt Fedora's
> community model.
Everyone's tied up with RPM vs. Deb that they can't think straight. It's
a big e-peen war that's not going to stop any time soon. The community
will be at a loss due to the bike-shedding that will continue for months.
>
> Even if this merger somehow turns out well for its target audience I
> think it is a very sad display of the mismanagement of an open source
> project.
MeeGo is a *brand-new* project run by two businesses that want to get
started and produce a device with MeeGo in a few months. Should they
have started at ground zero and asked "What glibc do you want? What
shell do you want? What package system do you want?" That would have
pushed them past 2010 to getting a 1.0 version out with the level of
bickering already present.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 03:22 PM
inode0
On Tue, Feb 16, 2010 at 9:37 AM, Michael Cronenworth <mike@cchtml.com> wrote:
> inode0 wrote:
>> If after developing for your favorite open source project for years
>> the company "sponsoring" that project decided tomorrow that it was
>> merging with another project and you would need to switch to a
>> different packaging system I suspect your reaction would be different.
>
> Grown men, some of which have been Debian users/developers since its
> inception, are bickering over this non-issue. It's a very fun thread to
> follow on how not to handle a serious situation.
I think it is largely misdirected angst resulting from the poor
community management practices that result in sudden changes like this
dropping out of a corporate news release one morning.
>> While it is true that there is a fair number of silly arguments about
>> the technical merits of the change, the real problem is that there was
>> no transparency in the decision process leading to the change. There
>> was no explanation that I have seen even stating clearly why the
>> change is being made. I'm guessing it is related to LSB issues and the
>> decision to have The Linux Foundation direct the project.
>
> It's been explained. The Moblin part of the merger is being used over
> the Maemo part. Simple as that.
Did they flip a coin? That is the way it worked out, that isn't a reason.
>> Rather than adopting Fedora's package management system what Nokia has
>> needed from the very beginning of maemo was to adopt Fedora's
>> community model.
>
> Everyone's tied up with RPM vs. Deb that they can't think straight. It's
> a big e-peen war that's not going to stop any time soon. The community
> will be at a loss due to the bike-shedding that will continue for months.
Sad but true and the result of Nokia not understanding how to work
with an open source community.
>> Even if this merger somehow turns out well for its target audience I
>> think it is a very sad display of the mismanagement of an open source
>> project.
>
> MeeGo is a *brand-new* project run by two businesses that want to get
> started and produce a device with MeeGo in a few months. Should they
> have started at ground zero and asked "What glibc do you want? What
> shell do you want? What package system do you want?" That would have
> pushed them past 2010 to getting a 1.0 version out with the level of
> bickering already present.
It if were brand new they could do whatever they pleased to create it.
But it isn't brand new. And it isn't just two businesses who can tell
their paid staff what to work on tomorrow. Does Fedora bicker over
which shell it wants? Does Red Hat require the shell to be bash? Who
makes that decision? This is getting as silly as the arguments over
rpm now.
I think if we compare how Fedora's "corporate sponsor" has gone about
helping to create, foster, and empower its community and compare that
with the Nokia/maemo relationship there are valuable things to be
learned.
John
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 03:32 PM
Michael Cronenworth
inode0 wrote:
> It if were brand new they could do whatever they pleased to create it.
> But it isn't brand new. And it isn't just two businesses who can tell
> their paid staff what to work on tomorrow.
How long has MeeGo be around for?
> Does Fedora bicker over
> which shell it wants? Does Red Hat require the shell to be bash? Who
> makes that decision? This is getting as silly as the arguments over
> rpm now.
Precisely what I was driving at.
>
> I think if we compare how Fedora's "corporate sponsor" has gone about
> helping to create, foster, and empower its community and compare that
> with the Nokia/maemo relationship there are valuable things to be
> learned.
>
I couldn't agree with you more, but there is hope in that Nokia is
pairing up on the effort and wishes to expand (explore?).
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 04:09 PM
inode0
On Tue, Feb 16, 2010 at 10:32 AM, Michael Cronenworth <mike@cchtml.com> wrote:
> inode0 wrote:
>> It if were brand new they could do whatever they pleased to create it.
>> But it isn't brand new. And it isn't just two businesses who can tell
>> their paid staff what to work on tomorrow.
>
> How long has MeeGo be around for?
This is semantics. Merging and renaming two existing things makes
something new out of something that already exists. There wouldn't be
any problem if it weren't for yanking an existing community from
something they have been contributing to for years into something else
with a press release.
>> Does Fedora bicker over
>> which shell it wants? Does Red Hat require the shell to be bash? Who
>> makes that decision? This is getting as silly as the arguments over
>> rpm now.
>
> Precisely what I was driving at.
But Fedora doesn't bicker about this. Red Hat doesn't mandate this.
Fedora as a community makes the decision. So why are we discussing it
at all? Having transparent governance and community decision making
does not mean bickering about such things.
>> I think if we compare how Fedora's "corporate sponsor" has gone about
>> helping to create, foster, and empower its community and compare that
>> with the Nokia/maemo relationship there are valuable things to be
>> learned.
>>
>
> I couldn't agree with you more, but there is hope in that Nokia is
> pairing up on the effort and wishes to expand (explore?).
This sentiment I think everyone shared in the beginning. Give Nokia
time to learn its way. But they began with old mistakes (core
controlled by them and the community contributing on the edges, sound
familiar?) and continue with a governance model that guarantees a
dysfunctional community that at each sudden jerk feels used. Hope may
spring eternal but eventually people get discouraged.
John
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 04:16 PM
Michael Cronenworth
inode0 wrote:
> This is semantics. Merging and renaming two existing things makes
> something new out of something that already exists. There wouldn't be
> any problem if it weren't for yanking an existing community from
> something they have been contributing to for years into something else
> with a press release.
You and I just think differently. People think differently. Thank goodness.
> But Fedora doesn't bicker about this. Red Hat doesn't mandate this.
> Fedora as a community makes the decision. So why are we discussing it
> at all? Having transparent governance and community decision making
> does not mean bickering about such things.
The problem is communication. With Maemo there was none. I can't say
much for Moblin as I haven't been involved at all.
> This sentiment I think everyone shared in the beginning. Give Nokia
> time to learn its way. But they began with old mistakes (core
> controlled by them and the community contributing on the edges, sound
> familiar?) and continue with a governance model that guarantees a
> dysfunctional community that at each sudden jerk feels used. Hope may
> spring eternal but eventually people get discouraged.
Yes, they are starting out the "same" but you should really Google or
read through some recent (as of this month) posts by @nokia folk that
have posted road maps and such that detail an overhaul of what they want
to accomplish. I'm holding out hope they follow that plan. You're free
to think Nokia won't change.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
02-16-2010, 04:24 PM
jack craig
On 02/16/2010 09:16 AM, Michael Cronenworth wrote:
>
> Yes, they are starting out the "same" but you should really Google or
> read through some recent (as of this month) posts by @nokia folk that
i did! it was full of resentful/fearful n900 & n800 users fearing
orphanages for their Nokia hw.
talking heads can blabber all the marketing speak they want, but
its the end user/developer whose opinion matters to me...
i am not putting my trust in Nokia. for that matter, i'll be real leery of
trusting Intel again, so much for stewardship! Not!
> have posted road maps and such that detail an overhaul of what they want
> to accomplish. I'm holding out hope they follow that plan. You're free
> to think Nokia won't change.
--
jack craig
jackc@LinuxLightHouse.com
831-684-1375 (Office)
831-596-6924 (cell)
IM: jackcraigaptos (AIM)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
