Re: JMX Remote connection
Costin Manolache wrote: No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) In the same spirit, I think we could imagine having a webapp for dynamic configuration of java logging. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) For those interested in not wasting their time the way I just did, I just found this: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html quote *Limitation*: On Windows, for security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports persistent access control lists (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls. /quote I obviously use FAT32, and I have to add that this limitation is quite stupid. No multi user setup would run FAT and expect security, so you are fine allowing anything you want on FAT (at least, I can't see how it makes stuff more secure). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: For those interested in not wasting their time the way I just did, I just found this: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html quote *Limitation*: On Windows, for security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports persistent access control lists (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls. /quote I obviously use FAT32, and I have to add that this limitation is quite stupid. No multi user setup would run FAT and expect security, so you are fine allowing anything you want on FAT (at least, I can't see how it makes stuff more secure). Ah... All my file systems are NTFS... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good That's not hard to add. You actually need the first free port in the range for rmiregistry - or you can use existing rmiregistry if one is found. You need different rmi names - that's easier. Adding user/pass/ssl is not hard - if someone has the itch it shouldn't be a problem. javax.man.remote has all that's needed AFAIK. IF you look at jmxremote webapp that I checked in - there is no mx4j or sun code, just plain javax. Costin -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Costin Manolache wrote: Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. Sorry. Windows, Solaris, and Linux do, and HPUX will soon. AIX and Mac OS X will lag as always, though if recent history is any guide AIX will lag further than Mac OS X. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 10:47 PM Subject: Re: JMX Remote connection Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 10:06 PM Subject: JMX Remote connection Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I thought JkMX only supports the old style connector - not the new javax.management.remote, and since jk2.properties is being deprecated I assumed JkMX will go as well, or at least move to a higher level. Yup. There isn't anything for javax.management.remote (other than the standard options in 1.5). The code in JkMX seems very specific to mx4j - and I couldn't get it working with mx4j2.0, the package name changed ( mx4j.adapter.rmi - mx4j.remote.rmi ) and the mechanism didn't seem to work. The mx4j.remote.rmi isn't included in the bin distro anymore (the source file is there, but deprecated). Can we at least add the JMXConnectionServerFactory as another special case ? A separate webapp seemed cleaner. It's a pain to do via reflection. The webapp does seem cleaner. Costin I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM 1.5) cheers, /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Dominik Drzewiecki wrote: Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM 1.5) Your post motivated me for trying jconsole, and I have to say it's really good. As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5. Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: Dominik Drzewiecki wrote: Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. Because they don't work with JDK1.4, and any people (including me) can't switch to Java5 since it breaks too much :-) The option you mention are in fact the same thing with the webapp I'm suggesting - they have the effect of loading the standard javax.management.remote connector. The difference is that jx.m.r is using the standard API and will work with any JMX implementation, while com.sun is specific to sun's implementation of jmx. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM 1.5) Your post motivated me for trying jconsole, and I have to say it's really good. Yes, jconsole is the reason I wrote the app too. Plus the fact that mx4j2.0 no longer works with jkmx ( they dumped the connector beans from distribution since they now support the standard jx.m.r ) As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5. Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed. No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Costin Manolache wrote: Remy Maucherat wrote: Dominik Drzewiecki wrote: Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. Because they don't work with JDK1.4, and any people (including me) can't switch to Java5 since it breaks too much :-) What are you talking about, it works great ;) The option you mention are in fact the same thing with the webapp I'm suggesting - they have the effect of loading the standard javax.management.remote connector. The difference is that jx.m.r is using the standard API and will work with any JMX implementation, while com.sun is specific to sun's implementation of jmx. Right, the exact parameter will be proprietary. However, every VM will have to provide a JMX remote implementation, and I think it's rather obvious there will be some way to enable it with some option or config file. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM 1.5) Your post motivated me for trying jconsole, and I have to say it's really good. Yes, jconsole is the reason I wrote the app too. Plus the fact that mx4j2.0 no longer works with jkmx ( they dumped the connector beans from distribution since they now support the standard jx.m.r ) I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5. Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed. No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) +1 for that webapp. Actually, we should include it in the compat package, since that package is for JDK 1.4. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html cut Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. /cut This reminds me of the bug I noticed while I was trying to get it work. It is impossible to select another account to run tomcat from within the tomcat service control. Will report it in bugzilla in a jiffie ;) cheers, /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JMX Remote connection
Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 10:06 PM Subject: JMX Remote connection Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 10:06 PM Subject: JMX Remote connection Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any official mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I thought JkMX only supports the old style connector - not the new javax.management.remote, and since jk2.properties is being deprecated I assumed JkMX will go as well, or at least move to a higher level. The code in JkMX seems very specific to mx4j - and I couldn't get it working with mx4j2.0, the package name changed ( mx4j.adapter.rmi - mx4j.remote.rmi ) and the mechanism didn't seem to work. Can we at least add the JMXConnectionServerFactory as another special case ? A separate webapp seemed cleaner. Costin I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even trusted ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]