[JBoss JIRA] (AS7-3754) COntent Repository not crash safe
by Bernd Eckenfels (JIRA)
Bernd Eckenfels created AS7-3754:
------------------------------------
Summary: COntent Repository not crash safe
Key: AS7-3754
URL: https://issues.jboss.org/browse/AS7-3754
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.Beta1
Reporter: Bernd Eckenfels
Assignee: Brian Stansberry
Priority: Minor
The moveTempToPermanent() Method in org.jboss.as.server.deployment.repository.impl.ContentRepositoryImpl which is used by DomainContentRepository for deploying artifacts has a problem with I/O error handling since closing the outputstream will ignore exceptions.
This is a problem since for two reasons, this can result in partial files without throwing a IOException: close() will invoke flush() which will write data which is not yet tried to be written. In addition on some environements (like NFS) the close method is actually the commit point. So close() of the output may not be shielded with a safeClose().
In addition to that the whole method can still create corrupt files if a crash happen. This is a problem since the existence of the file will stop other retries of storing the correct content (by existence). This can only be prevented by syncing the content before(!) the final rename.
BTW: since you read/write in 8k blocks there is no need to use Buffered Streams for in/out.
Sample code (without the initial synching of tmpFile and without the final renaming of the copy:
private void moveTempToPermanent(File tmpFile, File permanentFile) throws IOException {
// todo: make sure tmpFile is synced to disk
if (!tmpFile.renameTo(permanentFile)) {
FileOutputStream fos = null;
BufferedOutputStream bos = null;
FileInputStream fis = null;
try {
fos = new FileOutputStream(permanentFile); // TODO: use tempname in same dir
fis = new FileInputStream(tmpFile);
byte[] bytes = new byte[8192];
int read;
while ((read = fis.read(bytes)) > -1) {
fos.write(bytes, 0, read);
}
fos.flush();
fos.getFD().sync();
fos.close();
fos = null;
// rename here locally within same dir (always on same filesystem)
} finally {
safeClose(fos);
safeClose(fis);
if (!tmpFile.delete()) {
tmpFile.deleteOnExit();
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Jason Greene commented on AS7-3607:
-----------------------------------
Note that even if apr does bind to 127.0.0.1 vs ::ffff:127.0.0.1 the disadvantage is exceedingly small. An IPv6 client using ::ffff:127.0.0.1 to connect to port 8080 on an ipv4 binding will still succeed (that's the intention). The only failure case is if dual stack mode is disabled and someone has reassigned the ipv4 mapped space for ipv6 addresses.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-3607:
------------------------------------------
On the configuration issue which Remy mentioned, some guidance has been added on how to set up AS7 for IPv6: https://docs.jboss.org/author/display/AS71/Interfaces+and+ports
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz edited comment on AS7-3607 at 2/14/12 12:21 PM:
--------------------------------------------------------------------
Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752
When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.
I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the IPv4 socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets in the Http11Apr for IPv6 addresses in uncommon formats.
was (Author: rachmato):
Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752
When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.
I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets in the Http11Apr for IPv6 addresses in uncommon formats.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz edited comment on AS7-3607 at 2/14/12 12:20 PM:
--------------------------------------------------------------------
Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752
When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.
I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets in the Http11Apr for IPv6 addresses in uncommon formats.
was (Author: rachmato):
Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752
When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.
I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets for IPv6 addresses in uncommon formats.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-3607:
------------------------------------------
Rajesh's error is probably due to starting AS7 using an IPv6 stack and an IPv6 link-local address. I get the same problem and have logged a bug: https://issues.jboss.org/browse/AS7-3752
When you start the AS using an IPv6 stack and do not specify defaults for jboss.bind.address and jboss.bind.address.management, the defaults of 127.0.0.1 specified in the profile get assigned to the interfaces. Because the stack is IPv6, these get represented as the IPv6 addresses ::ffff:127.0.0.1 which are distinctly different from 127.0.0.1.
I suspect that when Http11Apr is being passed the IPv6 address ::ffff:127.0.0.1, it is somehow mistakenly treating it an IPv4 address and creating the socket accordingly. This does not happen if we pass in the IPv6 loopback address ::1 or a standard IPv6 global address -there IPv6 sockets are created. So rather than this being an issue about a system property, I suspect it's an issue with creation of sockets for IPv6 addresses in uncommon formats.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ]
Heiko Braun reassigned AS7-3042:
--------------------------------
Assignee: Darran Lofthouse
Darran, can you take a look at this?
> IPv6: Invalid redirect to Admin console (wrong IP address)
> ----------------------------------------------------------
>
> Key: AS7-3042
> URL: https://issues.jboss.org/browse/AS7-3042
> Project: Application Server 7
> Issue Type: Bug
> Components: Console, Web
> Affects Versions: 7.1.0.Beta1b
> Reporter: Pavel Janousek
> Assignee: Darran Lofthouse
> Fix For: Open To Community
>
>
> This issue is some derivation from AS7-3040. Lets imagine starting server like this:
> {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code}
> So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990.
> This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months