all.
I am trying to enable Felix framework security features on Apache Karaf(version 3.0 +),
but I could not find any official (or even unofficial) instructions on doing this.
The system.properties file (in Karaf/etc folder), in fact, contains following contents.
#
# Security properties
#
# To enable OSGi security, uncomment the properties below,
# install the framework-security feature and restart.
#
java.security.policy=${karaf.etc}/all.policy
org.osgi.framework.security=osgi
org.osgi.framework.trust.repositories=${karaf.etc}/trustStore.ks
When I uncomment those two properties and execute Karaf,
it gives the following error message:
Exception in thread "CM Configuration Updater" java.security.AccessControlException: access denied ("org.osgi.framework.AdaptPermission" "org.osgi.framework.wiring.BundleRevision" "adapt")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at org.apache.felix.framework.BundleImpl.checkAdapt(BundleImpl.java:1058)
at org.apache.felix.framework.BundleImpl.adapt(BundleImpl.java:1066)
In all.policy file, it looks like it is giving all the permissions required to all components:
grant {
permission java.security.AllPermission;
};
I've done some googling to find anyone else ran into this issue,
and I found this one: https://issues.apache.org/jira/browse/KARAF-3400
It says this issue actually arises due to a bug.
Is it really a bug or some minor configuration error?
Is there anyone succeeded in enabling felix security on Karaf version 3.0+?
Related
This is just for future reference since I solved it myself.
When I switched from logstash 2.x to 5.x, I was dealing with this warning (when I was runnig my logstash on this path D:\somepath\logstash-5.0.1):
Could not find log4j2 configuration at path /somepath/logstash-5.0.1/config/log4j2.properties. Using default config which logs to console
After some searching on internet and digging in ruby code (in the extracted logstash) I have found out this:
necessary to use path.settings (as mentioned many times) correctly
use correctly file or directory as URL path.
Finally I run my logstash as:
logstash.bat --path.settings=file://D:/somepath/logstash-5.0.1/config
OK, I have a similar problem as Download ClickOnce fails from setup.exe and Download ClickOnce fails from setup.exe , where I have deployed a ClickOnce installer for a desktop app I am selling.
Different than those examples, I am using Visual Studio 2012 (Pro Version). Using .Net 3.5. I am deploying on a hosted LINUX machine. It worked for me and other people running Windows 7 & 8, possibly earlier versions of Widnows. Then after running a few tests in Debug mode, I built and deployed in Release mode. Now, the auto-installer breaks when it gets to the spot where it wants to download the .application file. Here's the log file.
The following properties have been set:
Property: [AdminUser] = true {boolean}
Property: [InstallMode] = HomeSite {string}
Property: [NTProductType] = 1 {int}
Property: [ProcessorArchitecture] = AMD64 {string}
Property: [VersionNT] = 6.2.0 {version}
Running checks for package 'Microsoft Visual Basic PowerPacks 10.0', phase BuildList
Attempting to find 'Microsoft.VisualBasic.PowerPacks.Vs, Version=10.0.0.0, Culture=neutral, PublicKeyToken=YADDAYADDA' in the Global Assembly Cache
AssemblyCheck: Error querying assembly info: -2147024894
Attempting to find 'Microsoft.VisualBasic.PowerPacks.Vs, Version=10.0.0.0, Culture=neutral, PublicKeyToken=YADDAYADDA, processorArchitecture=msil' in the Global Assembly Cache
Assembly found at 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualBasic.PowerPacks.Vs\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.PowerPacks.Vs.dll'
Setting value '11.0.50727.1 {version}' for property 'VBPowerPacksInstalled'
The following properties have been set for package 'Microsoft Visual Basic PowerPacks 10.0':
Property: [VBPowerPacksInstalled] = 11.0.50727.1 {version}
Running checks for command 'VBPowerPacks\VisualBasicPowerPacksSetup.exe'
Result of running operator 'ValueExists' on property 'VBPowerPacksInstalled': true
Result of checks for command 'VBPowerPacks\VisualBasicPowerPacksSetup.exe' is 'Bypass'
'Microsoft Visual Basic PowerPacks 10.0' RunCheck result: No Install Needed
Running checks for package '.NET Framework 3.5 SP1', phase BuildList
Reading value 'SP' of registry key 'HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5'
Read integer value 1
Setting value '1 {int}' for property 'DotNet35SP'
The following properties have been set for package '.NET Framework 3.5 SP1': Property: [DotNet35SP] = 1 {int}
Running checks for command 'DotNetFX35SP1\dotNetFx35setup.exe'
Result of running operator 'ValueGreaterThanEqualTo' on property 'DotNet35SP' and value '1': true
Result of checks for command 'DotNetFX35SP1\dotNetFx35setup.exe' is 'Bypass'
'.NET Framework 3.5 SP1' RunCheck result: No Install Needed
Launching Application.
URLDownloadToCacheFile failed with HRESULT '-2146697205'
Error: An error occurred trying to download 'http://www.mywebsite.com/ProductName/Downloads/oneclick/ProductName.application'.
I've looked at https://msdn.microsoft.com/en-us/library/ms229001.aspx , after which I set the MIME type of .application to x-ms-application. No difference.
When I put the url http://www.mywebsite.com/ProductName/Downloads/oneclick/ProductName.application into my browser, I get the text of the file, rather than a download.
Any thoughts??? Thanks!
OK, the first thing that got me closer to the solution was simply to reboot the PC I was dwonloading onto. This got me further into the install, but I then ran into another problem, the solution to which I found at ClickOnce application replace current installed fliles . Clearing out the folder C:\Users\Charles\AppData\Local\Apps\2.0got me to where I could install and run the app fully.
Window application in C #. My solution, I hope it serves someone. The domain server was damaged, I just changed the IP of the new DNS server. It was not necessary to join that new domain server IP.
The "An error occurred trying to download.." error occurs with one of our click-once apps and the solution is to turn off IE Enhanced Security from Server Manager (Server 2012R2+) on the target machine.
UPDATE 8/6:
The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.
We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.
Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?
Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar
then the false(?) error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)
Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??
Original post:
I am intermittently getting an error when running a number of different Groovy scripts which all share an identical #Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:
#GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') #Grapes([
#Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
#Grab('commons-lang:commons-lang:2.3'),
#Grab('log4j:log4j:1.2.16'),
#Grab('gpars:gpars:0.12'),
#Grab('jsr166y:jsr166y:1.7.0'),
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
#Grab('org.apache.commons:commons-collections:3.2.1'),
#Grab('org.apache.httpcomponents:httpclient:4.2.2'),
#Grab('org.apache.httpcomponents:httpcore:4.2.3'),
#Grab('org.cyberneko.html:nekohtml:1.9.17'),
#Grab('xerces:xercesImpl:2.11.0'),
]) #GrabConfig(systemClassLoader = true)
Then the error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems:
1. Repository unreachable
2. Jar file doesn’t exist
However, in the artifactory logs, I've proven that the file is actually being downloaded:
*Artifactory did accept the request for download:
2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] libs-release-local:com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar for anonymous/165.226.40.155.
*Artifactory did deliver jar:
20140717075820|156|REQUEST|165.226.40.155|non_authenticated_user|GET|/libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar|HTTP/1.1|200|1276695
The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.
For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.
Questions:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
Does putting a try / catch block around the #Grab statements seem like a good idea? Or will that just hide the real problem?
thanks in advance!!!!
I think I finally figured out the answer to my own question.
I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.
Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.
I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:
-Dgrape.root=D:\Temp\grapeCache
UPDATE 8/19:
Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:
-Dgrape.config=D:\Temp\myGrapeConfig.xml
which had these contents:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
</chain>
</resolvers>
</ivysettings>
ALSO:
For completeness (further steps):
In Jenkins GUI, update the job(s):
a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6
b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):
-Dgrape.config=D:\Software\SfGrapeConfig.xml
Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
If you get this or a similar error:
"could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"
Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)
I am trying to test a Mozilla plugin (developed using FireBreath) in the form of an .so shared object file. The plugin was developed on Ubuntu, where it works fine.
I am now trying it under OpenSUSE - so I first symlinked the .so file in ~/.mozilla/plugins:
> ln -s /path/to/npXXX.so ~/.mozilla/plugins/
... and then ran Firefox (7) from command line:
> /path/to/firefox -P myprofile
...
LoadPlugin: failed to initialize shared library libXext.so [libXext.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /path/to/npXXX.so [/path/to/npXXX.so: undefined symbol: gtk_widget_get_mapped]
# and the LoadPlugin messages do NOT show a second time - probably because plugin is disabled (via about:addons).
And so I thought to try different stuff to look into this - but first, I restarted Firefox, and realized that on the second run I do not get the "LoadPlugin: failed to initialize" messages anymore! Then I tried removing the plugins symlink, and restarting FF; and adding it again, and restarting FF - still no error messages!
So, this tells me that probably Firefox somehow disabled/blacklisted the plugin (but which one: libXext, npXXX or both?) , but searching (grepping) for (np)XXX in '/path/to/myprofile/blocklist.xml' returns nothing (the plugin should use a email-like id, not those number GUIDs, so I'd expect that string to show in blocklist.xml if it's there).
Does anyone know: is the default behavior of Firefox to disable/blocklist plugins, that fail to load at first? If so, is there a way to force Firefox to load them again (and spit out error messages)? If you'd also have links to where this behavior is documented, it will be much appreciated :)
Many thanks in advance for any answers,
Cheers!
Note: after I stopped seeing the error messages, I did the following:
I am trying "about:plugins": "No enabled plugins found";
then trying "about:addons", and clicking under Plugins: "You don't have any add-ons of this type installed";
This plugin is not embedded in an extension, so nothing new should be added in "about:addons" under "Extensions" - and as expected, nothing new shows there. Under Ubuntu (where all works), just by symlinking the plugin to ~/.mozilla/plugins, the above two locations/screens start showing the plugin info.
This one of the things that puzzle me - if it just showed the plugin as "disabled", maybe I would have had a chance to re-enable it again (to get a new batch of error messages) - however, "about:plugins" and "about:addons" simply show nothing - so there's nothing I can use to enable from there. Which tells me Firefox has used a different method to disable the plugin(s) - but I cannot tell what it is...
Firefox has a cache for XPCOM modules ("fastload cache"), if a module fails to load Firefox won't try again. The cache is reset automatically if an extension is installed or if the application is updated. Starting with Firefox 4 you can also use -purgecaches command line flag to discard the cache.
I have PHP deprecated errors flooding log files and Drupal status pages like this:
: Function ereg() is deprecated in mysite/includes/file.inc on line 893.
I should be able to turn off E_DEPRECATED errors in my php.ini, but it is having no effect despite being set to:
error_reporting = E_ALL & ~E_DEPRECATED
phpInfo() reports error_reporting master value and local value both 22527.
I did a
grep -R error_reporting
in my document root in the hopes of finding any hard coded error levels and no luck:
./includes/common.inc: // If the # error suppression operator was used, error_reporting will have
./includes/common.inc: if (error_reporting() == 0) {
./modules/system/system.module: 'page arguments' => array('system_error_reporting_settings'),
./modules/system/system.admin.inc:function system_error_reporting_settings() {
./modules/system/system.install: $err = error_reporting(0);
./modules/system/system.install: error_reporting($err);
Nothing that I can see that is supect except possibly the first line in system.install but if I'm right that should turn all errors OFF.
I'm not setting error_reporting in .htaccess, but doing that does not have any effect either.
I'm hoping that there is a solution that doesn't involve hard coding error levels in common.inc (which DOES work, I've tried - but obviously undesirable).
I know the deprecated errors are a result of upgrading to PHP 5.3, but downgrading PHP is not option (new sites are going live now on the same server that have been tested on 5.3, and the sites where these errors occur have 2 months to live). I also cannot upgrade to Drupal versions that play nicely with 5.3 as unfortunately the previous owner haxxed the core modules without documenting his changes.
Version stuff:
PHP 5.3.2-1, Ubuntu 10.04, Drupal 6.13 on one site, 6.5 (!!1!) on the other, Apache 2.2
Did you try editing index.php to be
error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
I have used this on my php.ini file and could hide those deprecated errors. Hope it helps you! =)
error_reporting = E_ALL & ~E_DEPRECATED & -E_WARNING
I don't know about disabling error reporting but you can replace all ereg functions by preg_match..!