Cacti, SMTP (13) Permission denied

If you install a new instance of Cacti and can't send email, SELinux may be enabled.

 

# setenforcing 0

# vi /etc/sysconfig/selinux 

Exchange 2010 EMS, fail, fail, connect

TIP!

If your Exchange Management Console PowerShell shortcut (EMS) opens and tries to connect to a CAS multiple times, fails, then retries and succeeds.

[Immediately] suspect 'cruft' from add-on modules in the IISAdmin > Content > Explorer for the virtual folder for PowerShell in [web.config]

In this case it was leftover from an uninstalled module for Advanced Logging applications.

Exchange apparently timesout trying to load the module, or has other quality problems with the module and fails, it returns and randomly can eventually 'silently' fail to load the module and continue to provide a prompt.

But this can very confusingly and maddeningly leave you wondering why its taking so long, and there are [no] Event, IIS Logs or any other indications of problems.

I've seen this exact same thing in other contexts.. lesson Exchange depends on IIS but the bridge is very tenuous.. neither side appears to support the other very well with diagnostics.

Javax email, send hello error fix

javax depends on an environment variable to find the hostname when starting an SMTP msg hand-off to another server. The hostname can be set by a java developer so that it doesn't have to look it up, but a developer often skips or overlooks it. The method used to resolve the hostname between java and the os often breaks, especially in new linux distros (deprecation of network tools, refactoring of libraries, tossing things overboard). Under RHEL and Centos using the /etc/hosts file often fails if the hostname is appended to the end of along list of aliases, java only checks the first alias.

Fix:

make sure the hostname is placed at the front of a list of aliases in /etc/hosts

Example:

127.0.0.1 myhostname localhost localhost.localdomain

Internet Explorer 11, updating the user interface

Internet Explorer 11 is difficult to use and difficult to customize. Here is a way to make it easier to use.

The usual methods of customizing the user interface that worked with previous generations of the Internet Explorer browser no longer work. A way to work around this is to make the best of the IE settings available and then disable the components that no longer allow customization, replacing them with an add-on extension.

One such extension is the Quero Toolbar it installs in a fairly confusing default state.

To reach the state as displayed in the first image of this article, first download and install Quero Toolbar then open IE11 and press ALT+Q to get to its configuration menu.

Examine each tab in turn and make sure they are setup as follows:

Tab1 - Settings

Tab2 - Ad Blocker

Tab3 - Appearance

Tab4 - Search Profiles

Tab5 - Security

Tab6 - Advanced

Then right click in the exposed toolbar area of IE11 and change the selcted options to match this:

The default navigational icons will not be the colorful ones in these images, to get those you will need to visit the Quero Themes page and download the Crystal Theme, it consists of one DLL which contains the icons, save it to a place like your Documents directory, then visit the Tab3 - Appearance tab  from the Quero ALT+Q configuration menu and select the Theme by pressing the browse button at the bottom of the tab and selecting the Theme DLL.

All Browsers (IE, FF, Cr) have a hardware acceleration option. In general it attempts to offload some of the rendering to the local GPU.. in general it doesn't work very well and can cause problems and crashes.

If you would like to disable the hardware accelaration feature in IE11, it can be reached by left clicking on the 'gear' icon in the top right and selecting 'Internet Options' then the Advanced (tab) it will be the first item listed,  check it  and press [Apply] and then [OK]

The end result is a browser with a viewing and control profile very similar to what can be acheived in Firefox and Chrome.

Internet Explorer 11.0.9600.17959

Mozilla Firefox 40.0.2

Google Chrome 44.0.2403.155 m

note: while I am aware it is possible to go even further and make them virtually identical, this article was merely a quick demonstration of concept. current browsers are more similar than they are different in form and function, and regardless of their underlying differences can reach broader audiences by conforming to more common user interface elements.

Windows 2008r2, Powershell resuming a Service

The  Event Viewer  in Windows can start a  Task Scheduler  job when a specific  Windows log  entry is detected. The Powershell command language supports 'horizontal' line command scripting as well as 'vertical' line command scripting. So this can be encapsulated into a single line of instructions.

For example:

Start > Administrative Tools > Event Viewer

will start an instance of the Event Viewer discovery program focused on the (Local) binary logs

the categories down the vertical navigation panel to the Left generally indicate the source of a notification, Application (user), Security (kernel), System (system)

the levels in the central panel indicating "severity" more descriptive "source" and specific "event"

right-clicking an event and selecting "Attach Task To This Event"

will open a [Create Basic Task Wizard] window and create a Task Scheduler entry

the Action can be set to :

where the [Add arguments (optional):] field can be used to pass a 'horizonal' command line script

-command &{Start-Sleep -s 50; Restart-Service -displayname "StorageCraft ImageManger"}

in this case the script dictates to enter a sleep cycle for 50 seconds then peform a restart of a registered operating system service daemon with a displayname "StorageCraft ImageManager"

the actual "displaynames" of registered service processes can be obtained from a powershell prompt using the "get-service" command "let" or cmdlet, the displayname is not the same thing as the running process name

Tomcat, err ssl version or cipher mismatch

When using Tomcat  without  a robust web server frontend  ( like Apache or Nginx )  to manage SSL connections and sessions. Java keystore problems can produce several misleading error message in browsers. In addition to that, the imported certificate and private key used per website must have the same password/passphrase as the keystore itself and cannot be "blank".

The browser may display a cryptic error message and refuse to open an encrypted data channel using the certificate, resulting in an open http:// connection with the following message in the browser window:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Keytool does not have a method for importing a third party signed certificate and its private key into a new keystore natively.

The Openssl toolkit can create a Microsoft PCKS12 format cert and private key pair.

The Java keytool tool can then be used to import/convert a PCKS12 storage container into a keystore and set the "keypass" and "storepass" at the same time.

For example, it is common in Red Hat Enterprise Linux to use the /etc/pki/tls directories and genkey utilities from the crypto-utils package to create PEM encoded private key and CSR pairs and receive a signed PEM format CER cert. This is the least friction, most common method known of obtaining SSL certs and is fairly well documented.

The following will produce a keystore that contains the private key and signed cert in a keystore with the private key and keystore pass set to the same value:

# cd /etc/pki/tls

# openssl pkcs12 -export -in certs/www.server.com.cer -inkey private//www.server.com.key -out www.server.com.p12 -name tomcat -CAfile certs/ca_bundle.cer -caname root -chain

# mv www.server.com.p12 /usr/share/jdk1.7.0/bin/ ; cd /usr/share/jdk1.7.0/bin/

# keytool -importkeystore -deststorepass changeit! -destkeypass changeit! -destkeystore tomcat_java.keystore -srckeystore www.server.com.p12 -srcstoretype PKCS12 -srcstorepass changeit! -alias tomcat

 Since this keystore is intended to be used with Tomcat, the alias should be "tomcat"

Also since the server is now expected to provide the certificate chain, and in the correct order the following steps might be wise; It would be wise to also be aware that bundle files often come with multiple certs in one file and the keytool will silently discard and not import more than one certificate at a time, in which case if the file does contain multiple certificates breaking the file into one file per cert and importing them separately would be advised. The root of the chain possibly appearing as the "last" certificate in the bundled "chain file" and might need to be imported "first" in order to avoid problems with mobilty clients.

# keytool -import -trustcacerts -alias AddTrustExternalCARoot -file ca_bundle3.crt -keystore tomcat_java.keystore

# keytool -import -trustcacerts -alias USERTrustRSACA -file ca_bundle2.crt -keystore tomcat_java.keystore

# keytool -import -trustcacerts -alias RSAServerCA -file ca_bundle1.crt -keystore tomcat_java.keystore

And finally to address the ciphers problem.

The Tomcat connector ( server.xml ) needs to explicitly "tip toe" about known Common Vulnerabilities and Exploits (CVE)s, this may work like "magic" but the set is carefully crafted around a balance between known vulnerabilities, the capabilities of a jdk without enhanced cipher capabilties and what browsers will allow a connection to be formed with.

<Connector
port="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150"
SSLEnabled="true"
scheme="https"
keystoreFile="/usr/share/jdk1.7.0/bin/tomcat_java.keystore"
keystorePass="changeit!"
secure="true"
clientAuth="false"
sslProtocol="TLS"

ciphers="
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA
"
/>

Its best to consider carefully whether to forego using the "Free" wisdom and customs gathered and standardized by the more mature and currently very vital and active web server projects like Apache and Nginx. They are constantly being updated and repaired for Zero-Day attacks and exploits.

Java is a "language" and does not prioritize "web services" as a daily updated and maintained feature.. by "definition"

Tomcat is almost certainly "guaranteed" to be  "Exploitable"  the day it is released

To serve the useful purpose of an Example of   "What Not To Do.."   this has been widely and strongly publicized almost from its inception.

The position has not been changed, regardless of less experienced users promoting propaganda that "that's what they used to say.. it is still True Today  .. it is still in the documentation" it speaks highly of programmer experience level to say otherwise.

The AJP and Mod_jk projects explicitly "exist" because of the Java libraries that support them, they are not token projects that serve merely as examples.. they are there for a reason.. whenever "bindings" between projects exist and are maintained for "generations" do be curious and suspicious of why the the High Level of effort is continually put in place to maintain them.. usually unused code would fail over time if it were not actively being used. There Is A Reason.. Be Curious !!

Finally, Java "is a Language" with many aspects that "look like" an operating system, its JVM is not as old or robust.. or as well maintained by "language developers" as dedicated "operating system developers". A person who mows your lawn does not often fix cars as well as they mow lawns.. please keep this analogy in mind.

If "language developers" were to ever devote the same level of energy, effort and accumulated expertise.. you would probably not appreciate the language as much as a language developed by dedicated "language developers" [ Expertise in one area, does not often translate into "Unrelated" Expertise in another area.. to assume so is usually disasterous ]

RHEL 6, Installing Tomcat with Yum

Tomcat is a java Servlet, JSP web service provider. Red Hat Enterprise Linux doesn't install all of it without enabling the   Optional Subscription Channel   after RHN registration. Also an unresolved RPM java-gcj-compat requirement installs Java 1.5.0 gcj even if it is not used for running Tomcat.

The 'provides' tag was not added to subsequent newer versions of java as the gcj was gcj specific and is now for all intents and purposes retired. Sun, Oracle, IBM maintainers have no reason to add in this tag as a 'provides' and thus to satisfy the requirement pulls in the only java that satisfies it.. 1.5.0

There are ['ways'] of tricking the rpm dependency database into thinking it already has this requirement satisfied.. but they are not supported or approved by Red Hat.

Installing Tomcat without enabling the "Optional Subscription Channel" in RHN will result in a Tomcat service which has broken dependencies between java classes and java services in code written for the Tomcat service.

RHN Channel Subscription:

Subscribed Channels (Alter Channel Subscriptions)
[x] Red Hat Enterprise Linux Server (v.6 for x86_64)
|
+-> RHEL Server Optional (v.6 64-bit x86_64)

In particular the following package is only available from the "Optional Channel"

 jakarta-taglibs-standard    rhel-x86_64-server-optional-6

Pulling in Java 1.5.0 is suboptimal because Java 1.5.0 is no longer supported by its upstream provider.

However Java 1.8.0 changed and removed many of the java classes in use by a large portion of the web service code in common use today (i.e. Hashmaps).

Therefore it is more desirable to install Java 1.6.0 or Java 1.7.0

However while this is possible (and because the Alternatives symlinking will result in Tomcat running on the designated version of Java once it is installed) java 1.5.0 cannot be removed with the YUM package manager without causing a catastrophic "unwinding" that removes all packages that have the java-gcj-compat requirement.

To paraphrase the most recent statement from bug 1175457 

2015-05-12

This bug is not fixed, however a workaround is provided for rhel7. 

The true fix will probably never go into rhel6 

With these issues in mind the barest base install of Tomcat on RHEL 6.6 can be made with the command:

# yum groupinstall web-servlet

Which will install the following:

tomcat6
tomcat6-el-2.1-api
tomcat6-jsp-2.1-api
tomcat6-lib
tomcat6-servlet-2.5-api

It will provide a webservice, but serve a completely [blank] page.

http://localhost:8080/

[ don't forget about - iptables and selinux ]

The following packages [will not be installed] but you may expect and wish to install them:

tomcat6-admin-webapps
tomcat6-docs-webapp
tomcat6-javadoc
tomcat6-log4j
tomcat6-webapps

One reason is that these other packages pull in even more dependencies for supporting the Example and Sample JSP and Servlet applications, which "people tend to install tomcat because they want to serve JSP and Servlet applications.."

If you install only the group web-servlet, your very secure.. but most of your JSP and Servlet apps will not work unless you selectively install supporting packaged versions of support software for JSP and Servlet apps. Kind of a knock on side-effect. Figuring out which packages contain those support services.. is "fun"

Upon enabling the Optional Channel and installing all of the packages, Tomcat behaves more like a freshly compiled source code distribution.

By installing an alternate version of java [before] the java_1.5.0 version is pulled in by a dependency (i.e. on a freshly installed server) the later version of java will take priority and keep the alternatives pointers fixed on the newer version of java [ alternatively the "alternatives" command can be used to manually adjust the pointers, however its just easier to install a different java version before 1.5.0 is pulled in ] [ the non-devel package will pull in only the java runtimes JRE, the "-devel" package will pull in the java development kit javac compiler JDK which could be useful ]

# yum install java-1.7.0-openjdk  java-1.7.0-openjdk-devel

# yum install tomcat6 tomcat6-el-2.1-api tomcat6-jsp-2.1-api tomcat6-lib tomcat6-servlet-2.5-api tomcat6-admin-webapps tomcat6-docs-webapp tomcat6-javadoc tomcat6-log4j tomcat6-webapps

The APR, OpenSSL, JNI - libtcnative.so or tomcat-native component is apparently not available as a packaged option on RHEL6. While facility to accomodate it was made in the /etc/sysconfig/tomcat6 file under JAVA_OPTS= it was never packaged for the x86_64 architecture.

It can in theory be compiled and inserted into the /usr/lib64 path "since it is in fact a C" library. But then you run the risk of further maintenance addressing CVEs and other Security audits.

For RHEL7 and Tomcat 7.0 it appears libtcnative may be available as a packaged option.

EPEL and RHSCL also do not appear to offer much support for Tomcat6 on RHEL6.

JBoss however, if contracted and installed, does appear to have a libtcnative however that is not to my knowlege a generally supported option unless you are running that platform.