[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski updated AS7-6031:
------------------------------------
Attachment: deployment_with_hack_no_hook.txt
ls -alR
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski commented on AS7-6031:
-----------------------------------------
'W' - with hack
'W/O' - no hack to cleanup tmp
No deployment with shutdown hook
{noformat}
W W/O
1. 3064ms 2858ms
2. 3028ms 2790ms
3. 2960ms 2831ms
4. 3061ms 2917ms
5. 2977ms 2828ms
6. 2958ms 2843ms
7. 2909ms 2872ms
8. 2898ms 2856ms
9. 2945ms 2915ms
10. 2937ms 2969ms
{noformat}
No deployment without shutdown hook '-Xrs'
{noformat}
1. 2903ms 2796ms
2. 2854ms 2943ms
3. 2941ms 2808ms
4. 2937ms 2935ms
5. 3234ms 2964ms
6. 2922ms 2862ms
7. 2829ms 2841ms
8. 2854ms 2885ms
9. 2931ms 2874ms
10. 2975ms 2922ms
{noformat}
ls -laR ( part of it, after W/O runs
{noformat}
ls -laR standalone/tmp/
total 20
drwxrwxr-x 5 baranowb baranowb 4096 2013-01-10 11:20 .
drwxrwxr-x 8 baranowb baranowb 4096 2013-01-10 11:20 ..
drwx------ 2 baranowb baranowb 4096 2013-01-10 11:18 auth
drwxrwxr-x 15 baranowb baranowb 4096 2013-01-10 11:28 vfs
drwxrwxr-x 3 baranowb baranowb 4096 2013-01-10 11:20 work
standalone/tmp/auth:
total 8
drwx------ 2 baranowb baranowb 4096 2013-01-10 11:18 .
drwxrwxr-x 5 baranowb baranowb 4096 2013-01-10 11:20 ..
standalone/tmp/vfs:
total 60
drwxrwxr-x 15 baranowb baranowb 4096 2013-01-10 11:28 .
drwxrwxr-x 5 baranowb baranowb 4096 2013-01-10 11:20 ..
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:20 temp22b2c3b8d74354
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:20 temp269ff1e8171ea873
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:23 temp35501bb7f0ce71e9
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:23 temp3aade92f81fedb68
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:26 temp47abae8a39472109
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:26 temp4d48ba76bb40266d
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:25 temp637e885234a2a17f
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:23 temp7072ea6391eafbf3
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:28 tempa64d5ddb1e490c42
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:26 tempac343cb5209d61b9
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:24 tempc7627e794eb55c6b
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:26 tempcf0338e402de1067
drwxrwxr-x 2 baranowb baranowb 4096 2013-01-10 11:20 tempd1beed9b1b302b7c
{noformat}
Deployment, with shutdown hook
{noformat}
W W/O
1. 7684ms/285ms 7996ms/236ms
2. 7959ms/256ms 7795ms/234ms
3. 7772ms/279ms 7633ms/248ms
4. 7445ms/244ms 7950ms/218ms
5. 8033ms/264ms 7822ms/230ms
6. 7888ms/310ms 7673ms/223ms
7. 7642ms/221ms 7739ms/302ms
8. 7890ms/264ms 7920ms/1952ms (wow)
9. 7367ms/208ms 7242ms/301ms
10. 7548ms/243ms 7528ms/195ms
{noformat}
Deployment, with out shutdown hook '-Xrs'
{noformat}
W W/O
1. 7864ms 7783ms
2. 7653ms 7406ms
3. 7505ms 7926ms
4. 7685ms 7759ms
5. 7808ms 7730ms
6. 7796ms 7336ms
7. 7822ms 7223ms
8. 7589ms 7758ms
9. 7589ms 7952ms
10. 7818ms 7366ms
{noformat}
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6308) CLI deploy on windows only treats C:\ forms as absolute
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/AS7-6308?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky commented on AS7-6308:
----------------------------------------
Yes, that would work. Or reading the description of File.isAbsolute():
"...On Microsoft Windows systems, a pathname is absolute if its prefix is a drive specifier followed by "\\", or if its prefix is "\\\\"."
Thanks.
> CLI deploy on windows only treats C:\ forms as absolute
> -------------------------------------------------------
>
> Key: AS7-6308
> URL: https://issues.jboss.org/browse/AS7-6308
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: James Livingston
> Assignee: Alexey Loubyansky
>
> WindowsFilenameTabCompleter.startsWithRoot() is implemented to treat strings containing :\ as absolute paths.
> This does not handle UNC paths (network shares) which start with a double backslash. The rest of the path is also not sensitive to whether you use forward or backward slashes, so perhaps it should consider paths containing :/ as absolute too.
> Are there situations where "new File(path).isAbsolute()" would not work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/SECURITY-719?page=com.atlassian.jira.plug... ]
Marek Posolda commented on SECURITY-719:
----------------------------------------
Just a note that issue can be reproduced with latest AS7 master and negotiation 2.2.2.Final.
I needed quick fix available today for JPP6, so I workaround for GateIn with commit https://github.com/mposolda/gatein-sso/commit/630208526f669beb9132172c6f0..., which simply rewrite the session_systemTime token with real username in the principal returned from jbossweb realm.
> request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
> -------------------------------------------------------------------
>
> Key: SECURITY-719
> URL: https://issues.jboss.org/browse/SECURITY-719
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Environment: EAP 6.0.1.ER4.2
> SPNEGO setup with Kerberos
> Kerberos user: demo(a)LOCAL.NETWORK
> Reporter: Marek Posolda
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_2_2
>
>
> It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit.
> I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs:
> request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK
> request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!!
> SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!!
> Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan.
> In NegotiationAuthenticator the call to JBossWebRealm:
> principal = realm.authenticate(username, (String) null);
> now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time.
> Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK".
> So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6309) Verify audit implications and required APIs
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-6309:
-------------------------------------
Summary: Verify audit implications and required APIs
Key: AS7-6309
URL: https://issues.jboss.org/browse/AS7-6309
Project: Application Server 7
Issue Type: Sub-task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.3.0.Alpha1
Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected.
i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBRULES-3712) Logging of multiple Solvers in parallel is confusing: support MDC to make them readable
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3712?page=com.atlassian.jira.plug... ]
Geoffrey De Smet commented on JBRULES-3712:
-------------------------------------------
Quick hack is to add the MDC lines before and after SingleBenchmark.call()
But we want to support this in production too, for SaaS etc.
> Logging of multiple Solvers in parallel is confusing: support MDC to make them readable
> ---------------------------------------------------------------------------------------
>
> Key: JBRULES-3712
> URL: https://issues.jboss.org/browse/JBRULES-3712
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-planner
> Reporter: Geoffrey De Smet
> Assignee: Geoffrey De Smet
>
> Basically we want this kind of logging output when running 3 solvers in parallel:
> {code}
> Solver1 INFO Step (34)
> Solver1 INFO Step (35)
> Solver2 INFO Step (88)
> Solver1 INFO Step (36)
> Solver2 INFO Step (89)
> Solver7 INFO Step (10)
> Solver3 INFO Step (37)
> {code}
> but we don't want to prefix every logging message with the solver name, that's a big pita. Luckily:
> SLF4j exposes MDC's which make this a breeze:
> http://logback.qos.ch/manual/mdc.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBRULES-3712) Logging of multiple Solvers in parallel is confusing: support MDC to make them readable
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created JBRULES-3712:
-----------------------------------------
Summary: Logging of multiple Solvers in parallel is confusing: support MDC to make them readable
Key: JBRULES-3712
URL: https://issues.jboss.org/browse/JBRULES-3712
Project: JBRULES
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Basically we want this kind of logging output when running 3 solvers in parallel:
{code}
Solver1 INFO Step (34)
Solver1 INFO Step (35)
Solver2 INFO Step (88)
Solver1 INFO Step (36)
Solver2 INFO Step (89)
Solver7 INFO Step (10)
Solver3 INFO Step (37)
{code}
but we don't want to prefix every logging message with the solver name, that's a big pita. Luckily:
SLF4j exposes MDC's which make this a breeze:
http://logback.qos.ch/manual/mdc.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6302) xa-datasource-properties are not writable
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6302?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri resolved AS7-6302.
----------------------------------
Resolution: Rejected
The attribute value is declared read-only as you can see from a :read_resource-description. xa-datasource-properties are subresources and can be removed and added (also w/o a reload-required on a disabled database), that is different from write an atrribute. I don't see any inconsistency there.
> xa-datasource-properties are not writable
> -----------------------------------------
>
> Key: AS7-6302
> URL: https://issues.jboss.org/browse/AS7-6302
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
> Reporter: Akram Ben Aissi
> Assignee: Stefano Maestri
>
> When trying to change a value of an xa-datasource-properties with the following command:
> {code}
> /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:write-attribute(name=value,value=Test)
> {code}
> One gets an error messaging saying:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014639: Attribute value is not writable",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> However, the attribute can be removed and then re-added with different value, leading to a reload-required:
> {code}
> [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:remove()
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=User:add(value=Test)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9999 /]
> {code}
> To be consistent, the attribute value should be writable and also leads to a reload-required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months