You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "Dr. Hans-Peter Störr" <sp...@planet.ms> on 2022/03/16 17:59:05 UTC

Starting a FAR with the Sling feature launcher without network access

Hi!

I'm wondering about use usage of feature archives in the Sling feature launcher, especially in a setting without a network and $HOME/.m2/repository.
https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/feature-archives.md says the feature archives, such as the org.apache.sling.starter-12-oak_tar_far.far produced by the Sling Starter https://github.com/apache/sling-org-apache-sling-starter , are meant to contain the actual artifacts needed to run the system. Yet, when you start the system like this:

java -jar org.apache.sling.feature.launcher.jar -f org.apache.sling.starter-12-oak_tar_far.far -v

the log shows that the artifacts in the FAR are completely ignored - it takes these from $HOME/.m2/repository or, failing that, they are downloaded from https://repo.maven.apache.org/maven2 . That seems not only a waste of network resources, but it has its problems. First in intranets or in a DMZ it's not guaranteed that you have internet access. Even worse: on production systems you don't want the starter to access the network or getting files from $HOME/.m2/repository, since that offers various attack avenues for injecting code into the system. So I'm wondering: shouldn't the feature launcher first check the FAR for the artifact and use that? Or even only use the code contained in a FAR?


That said: there actually is a way to start the launcher without using the network, but in a quite cumbersome way. The feature launcher allows specifying the repository URLs, and you can give a jar file URL as repository URL:

java -jar org.apache.sling.feature.launcher.jar -f org.apache.sling.starter-12-oak_tar_far.far -u 'jar:file:org.apache.sling.starter-12-oak_tar_far.far!' -u 'jar:file:felixcontainer.zip!'

This also adds a second zip I created as a repository for the felix framework, which is required by the launcher, and just contains the file
org/apache/felix/org.apache.felix.framework/7.0.1/org.apache.felix.framework-7.0.1.jar

This works completely without network access, but it does feel like a workaround. So, is that actually the intended solution for this usecase, or are there plans to extend the feature launcher in some way? Or am I missing something?

Thank you all for the good work and the many advances with this!

Best regards,

Hans-Peter

PS: I was almost jumping up and down when I saw the tag org.apache.sling.starter-12 in the maven repo. Thanks for finally fixing something that can become release 12 of the Sling Starter ! I'm looking forward for it to appear in the maven repository.

Aw: Re: Starting a FAR with the Sling feature launcher without network access

Posted by "Dr. Hans-Peter Störr" <sp...@planet.ms>.
Hi!

Thank you for your answers! I created https://issues.apache.org/jira/browse/SLING-11220 about that.

Best regards,

Hans-Peter


Re: Starting a FAR with the Sling feature launcher without network access

Posted by Eric Norman <en...@apache.org>.
Hi Hans-Peter,

Thanks for confirming.  At this point it would be best to open a new bug
report with your findings so the required changes that Carsten mentioned
can be tracked.

Also, do you think it would be useful for the feature launcher assembly
(that was created for SLING-10956) to be enhanced to include the felix
framework bundle so you don't have to download and prepare that separately?

Regards,
- Eric

On Thu, Mar 17, 2022 at 9:30 AM Carsten Ziegeler <cz...@apache.org>
wrote:

> It seems this line:
>
>
> https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/master/src/main/java/org/apache/sling/feature/launcher/impl/FeatureProcessor.java#L120
>
> is the culprit; it checks the provider (all repositories) instead of
> just the cache.
>
> Regards
> Carsten
>
> Am 17.03.2022 um 12:42 schrieb Carsten Ziegeler:
> > Hi,
> >
> > I agree the launcher should be able to properly handle FAR files and use
> > the artifacts from within the FAR; I don't think we need a switch to
> > control this.
> > The launcher should check in the cache first, then the FAR file and then
> > the configured repositories.
> >
> > Regards
> > Carsten
> >
> > Am 17.03.2022 um 12:14 schrieb Dr. Hans-Peter Störr:
> >> Hi Eric!
> >>
> >> Thanks for your answer! Ah, indeed I let myself be confused by the
> >> loads of stacktraces that are logged. You are right: if I try
> >>
> >> java -jar org.apache.sling.feature.launcher.jar -f
> >> org.apache.sling.starter-12-oak_tar_far.far -u
> >> 'jar:file:felixcontainer.zip!'
> >>
> >> that works, too - but after logging some 2900 lines with more than 245
> >> stacktraces like this:
> >>
> >>   [INFO] Artifact not found in one repository
> >>   java.io.FileNotFoundException: JAR entry
> >> commons-codec/commons-codec/1.15/commons-codec-1.15.jar not found in
> >> felixcontainer.zip
> >>           at
> >>
> java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:147)
>
> >>
> >>           at
> >> org.apache.sling.feature.io.artifacts.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:424)
>
> >>
> >>           at
> >> org.apache.sling.feature.io.artifacts.ArtifactManager.getArtifactHandler(ArtifactManager.java:248)
>
> >>
> >>           at
> >>
> org.apache.sling.feature.launcher.impl.FeatureProcessor$1.provide(FeatureProcessor.java:86)
>
> >>
> >>           at
> >>
> org.apache.sling.feature.launcher.impl.FeatureProcessor.lambda$createApplication$4(FeatureProcessor.java:120)
>
> >>
> >>           at
> >> org.apache.sling.feature.io.archive.ArchiveReader.read(ArchiveReader.java:121)
>
> >>
> >>           at
> >>
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:118)
>
> >>
> >>           at
> >>
> org.apache.sling.feature.launcher.impl.Bootstrap.assemble(Bootstrap.java:208)
>
> >>
> >>           at
> >> org.apache.sling.feature.launcher.impl.Bootstrap.run(Bootstrap.java:123)
> >>           at
> >> org.apache.sling.feature.launcher.impl.Main.main(Main.java:402)
> >>
> >> So I'd certainly suggest to remove the stacktrace on these messages,
> >> and maybe even demote them to DEBUG messages so that they only appear
> >> when -v is given.
> >>
> >> But I'm still wondering whether the launcher should even look into the
> >> repositories if the artifact is in the FAR. Maybe there should be a
> >> switch to turn that off. There is some sense to that in a development
> >> setting (it seems an updated JAR in $HOME/.m2/repository gets replaced
> >> on launcher restart), but not if you set up a server.
> >>
> >> Thanks and best regards,
> >>
> >> Hans-Peter
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>

Re: Starting a FAR with the Sling feature launcher without network access

Posted by Carsten Ziegeler <cz...@apache.org>.
It seems this line:

https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/master/src/main/java/org/apache/sling/feature/launcher/impl/FeatureProcessor.java#L120

is the culprit; it checks the provider (all repositories) instead of 
just the cache.

Regards
Carsten

Am 17.03.2022 um 12:42 schrieb Carsten Ziegeler:
> Hi,
> 
> I agree the launcher should be able to properly handle FAR files and use 
> the artifacts from within the FAR; I don't think we need a switch to 
> control this.
> The launcher should check in the cache first, then the FAR file and then 
> the configured repositories.
> 
> Regards
> Carsten
> 
> Am 17.03.2022 um 12:14 schrieb Dr. Hans-Peter Störr:
>> Hi Eric!
>>
>> Thanks for your answer! Ah, indeed I let myself be confused by the 
>> loads of stacktraces that are logged. You are right: if I try
>>
>> java -jar org.apache.sling.feature.launcher.jar -f
>> org.apache.sling.starter-12-oak_tar_far.far -u
>> 'jar:file:felixcontainer.zip!'
>>
>> that works, too - but after logging some 2900 lines with more than 245 
>> stacktraces like this:
>>
>>   [INFO] Artifact not found in one repository
>>   java.io.FileNotFoundException: JAR entry 
>> commons-codec/commons-codec/1.15/commons-codec-1.15.jar not found in 
>> felixcontainer.zip
>>           at 
>> java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:147) 
>>
>>           at 
>> org.apache.sling.feature.io.artifacts.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:424) 
>>
>>           at 
>> org.apache.sling.feature.io.artifacts.ArtifactManager.getArtifactHandler(ArtifactManager.java:248) 
>>
>>           at 
>> org.apache.sling.feature.launcher.impl.FeatureProcessor$1.provide(FeatureProcessor.java:86) 
>>
>>           at 
>> org.apache.sling.feature.launcher.impl.FeatureProcessor.lambda$createApplication$4(FeatureProcessor.java:120) 
>>
>>           at 
>> org.apache.sling.feature.io.archive.ArchiveReader.read(ArchiveReader.java:121) 
>>
>>           at 
>> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:118) 
>>
>>           at 
>> org.apache.sling.feature.launcher.impl.Bootstrap.assemble(Bootstrap.java:208) 
>>
>>           at 
>> org.apache.sling.feature.launcher.impl.Bootstrap.run(Bootstrap.java:123)
>>           at 
>> org.apache.sling.feature.launcher.impl.Main.main(Main.java:402)
>>
>> So I'd certainly suggest to remove the stacktrace on these messages, 
>> and maybe even demote them to DEBUG messages so that they only appear 
>> when -v is given.
>>
>> But I'm still wondering whether the launcher should even look into the 
>> repositories if the artifact is in the FAR. Maybe there should be a 
>> switch to turn that off. There is some sense to that in a development 
>> setting (it seems an updated JAR in $HOME/.m2/repository gets replaced 
>> on launcher restart), but not if you set up a server.
>>
>> Thanks and best regards,
>>
>> Hans-Peter
>>
> 

-- 
Carsten Ziegeler
Adobe
cziegeler@apache.org

Re: Starting a FAR with the Sling feature launcher without network access

Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,

I agree the launcher should be able to properly handle FAR files and use 
the artifacts from within the FAR; I don't think we need a switch to 
control this.
The launcher should check in the cache first, then the FAR file and then 
the configured repositories.

Regards
Carsten

Am 17.03.2022 um 12:14 schrieb Dr. Hans-Peter Störr:
> Hi Eric!
> 
> Thanks for your answer! Ah, indeed I let myself be confused by the loads of stacktraces that are logged. You are right: if I try
> 
> java -jar org.apache.sling.feature.launcher.jar -f
> org.apache.sling.starter-12-oak_tar_far.far -u
> 'jar:file:felixcontainer.zip!'
> 
> that works, too - but after logging some 2900 lines with more than 245 stacktraces like this:
> 
>   [INFO] Artifact not found in one repository
>   java.io.FileNotFoundException: JAR entry commons-codec/commons-codec/1.15/commons-codec-1.15.jar not found in felixcontainer.zip
>           at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:147)
>           at org.apache.sling.feature.io.artifacts.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:424)
>           at org.apache.sling.feature.io.artifacts.ArtifactManager.getArtifactHandler(ArtifactManager.java:248)
>           at org.apache.sling.feature.launcher.impl.FeatureProcessor$1.provide(FeatureProcessor.java:86)
>           at org.apache.sling.feature.launcher.impl.FeatureProcessor.lambda$createApplication$4(FeatureProcessor.java:120)
>           at org.apache.sling.feature.io.archive.ArchiveReader.read(ArchiveReader.java:121)
>           at org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:118)
>           at org.apache.sling.feature.launcher.impl.Bootstrap.assemble(Bootstrap.java:208)
>           at org.apache.sling.feature.launcher.impl.Bootstrap.run(Bootstrap.java:123)
>           at org.apache.sling.feature.launcher.impl.Main.main(Main.java:402)
> 
> So I'd certainly suggest to remove the stacktrace on these messages, and maybe even demote them to DEBUG messages so that they only appear when -v is given.
> 
> But I'm still wondering whether the launcher should even look into the repositories if the artifact is in the FAR. Maybe there should be a switch to turn that off. There is some sense to that in a development setting (it seems an updated JAR in $HOME/.m2/repository gets replaced on launcher restart), but not if you set up a server.
> 
> Thanks and best regards,
> 
> Hans-Peter
> 

-- 
Carsten Ziegeler
Adobe
cziegeler@apache.org

Aw: Re: Starting a FAR with the Sling feature launcher without network access

Posted by "Dr. Hans-Peter Störr" <sp...@planet.ms>.
Hi Eric!

Thanks for your answer! Ah, indeed I let myself be confused by the loads of stacktraces that are logged. You are right: if I try

java -jar org.apache.sling.feature.launcher.jar -f
org.apache.sling.starter-12-oak_tar_far.far -u
'jar:file:felixcontainer.zip!'

that works, too - but after logging some 2900 lines with more than 245 stacktraces like this:

 [INFO] Artifact not found in one repository
 java.io.FileNotFoundException: JAR entry commons-codec/commons-codec/1.15/commons-codec-1.15.jar not found in felixcontainer.zip
         at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:147)
         at org.apache.sling.feature.io.artifacts.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:424)
         at org.apache.sling.feature.io.artifacts.ArtifactManager.getArtifactHandler(ArtifactManager.java:248)
         at org.apache.sling.feature.launcher.impl.FeatureProcessor$1.provide(FeatureProcessor.java:86)
         at org.apache.sling.feature.launcher.impl.FeatureProcessor.lambda$createApplication$4(FeatureProcessor.java:120)
         at org.apache.sling.feature.io.archive.ArchiveReader.read(ArchiveReader.java:121)
         at org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:118)
         at org.apache.sling.feature.launcher.impl.Bootstrap.assemble(Bootstrap.java:208)
         at org.apache.sling.feature.launcher.impl.Bootstrap.run(Bootstrap.java:123)
         at org.apache.sling.feature.launcher.impl.Main.main(Main.java:402)

So I'd certainly suggest to remove the stacktrace on these messages, and maybe even demote them to DEBUG messages so that they only appear when -v is given.

But I'm still wondering whether the launcher should even look into the repositories if the artifact is in the FAR. Maybe there should be a switch to turn that off. There is some sense to that in a development setting (it seems an updated JAR in $HOME/.m2/repository gets replaced on launcher restart), but not if you set up a server.

Thanks and best regards,

Hans-Peter


Re: Starting a FAR with the Sling feature launcher without network access

Posted by Eric Norman <en...@apache.org>.
I haven't looked too closely at this, but if I recall correctly, when using
the launcher with a .far it seemed like the logged count of local artifacts
was more than double the number before so I'm not sure if it is ignored
completely?  It seemed like it was counting the artifacts inside the .far
and the artifacts in the local maven repo too even if they were
duplicates.   I thought that was weird, but it didn't bother me enough to
look further.

Are you saying that running with a non-empty "-u" argument that completely
replaces the default repository urls is unable to run?

For example, if your -u arguments are just the zip containing the feix
framework with something like below, is it able to find the artifacts that
exist inside the far archive?

java -jar org.apache.sling.feature.launcher.jar -f
org.apache.sling.starter-12-oak_tar_far.far -u
'jar:file:felixcontainer.zip!'

Regards,
-Eric

On Wed, Mar 16, 2022 at 10:59 AM Dr. Hans-Peter Störr <sp...@planet.ms>
wrote:

> Hi!
>
> I'm wondering about use usage of feature archives in the Sling feature
> launcher, especially in a setting without a network and
> $HOME/.m2/repository.
>
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/docs/feature-archives.md
> says the feature archives, such as the
> org.apache.sling.starter-12-oak_tar_far.far produced by the Sling Starter
> https://github.com/apache/sling-org-apache-sling-starter , are meant to
> contain the actual artifacts needed to run the system. Yet, when you start
> the system like this:
>
> java -jar org.apache.sling.feature.launcher.jar -f
> org.apache.sling.starter-12-oak_tar_far.far -v
>
> the log shows that the artifacts in the FAR are completely ignored - it
> takes these from $HOME/.m2/repository or, failing that, they are downloaded
> from https://repo.maven.apache.org/maven2 . That seems not only a waste
> of network resources, but it has its problems. First in intranets or in a
> DMZ it's not guaranteed that you have internet access. Even worse: on
> production systems you don't want the starter to access the network or
> getting files from $HOME/.m2/repository, since that offers various attack
> avenues for injecting code into the system. So I'm wondering: shouldn't the
> feature launcher first check the FAR for the artifact and use that? Or even
> only use the code contained in a FAR?
>
>
> That said: there actually is a way to start the launcher without using the
> network, but in a quite cumbersome way. The feature launcher allows
> specifying the repository URLs, and you can give a jar file URL as
> repository URL:
>
> java -jar org.apache.sling.feature.launcher.jar -f
> org.apache.sling.starter-12-oak_tar_far.far -u
> 'jar:file:org.apache.sling.starter-12-oak_tar_far.far!' -u
> 'jar:file:felixcontainer.zip!'
>
> This also adds a second zip I created as a repository for the felix
> framework, which is required by the launcher, and just contains the file
>
> org/apache/felix/org.apache.felix.framework/7.0.1/org.apache.felix.framework-7.0.1.jar
>
> This works completely without network access, but it does feel like a
> workaround. So, is that actually the intended solution for this usecase, or
> are there plans to extend the feature launcher in some way? Or am I missing
> something?
>
> Thank you all for the good work and the many advances with this!
>
> Best regards,
>
> Hans-Peter
>
> PS: I was almost jumping up and down when I saw the tag
> org.apache.sling.starter-12 in the maven repo. Thanks for finally fixing
> something that can become release 12 of the Sling Starter ! I'm looking
> forward for it to appear in the maven repository.
>