Traversability of Networks (Durchlaufbarkeit von Netzen)

I panicked the other day when my ten year old son, as part of his homework, asked me about traversing graphs.  Even worse, the following day, he was to have a test and was supposed to be able to determine if one could travel along every edge of a given graph only once without lifting the pencil from the paper after having started and whether or not it was possible to end up at the starting point.

When it is possible to do so, then the graph is said to contain an Euler cycle or circuit and is often referred to as an Eulerian graph after the famous Swiss mathematician Leonhard Euler, who dealt with such puzzles while solving the famous Seven Bridges of Königsberg problem in 1736.

If it’s possible to traverse over every edge only once but not end up at the starting point, then the graph is said to contain an Euler trail or path.

The rules for determining whether a graph has an Euler circuit, Euler path or neither, is unsolveable, can be summed up as follows:

For Euler circuits, or Eulerian graphs, every node or vertex of the graph must be of an even degree (the degree of a vertex is counted by the number of edge, which are connected to it).

For graphs that only have a path but no circuit, there can only be two odd vertices present. The presence of one, three or more odd vertices means that it is not possible to completely traverse the graph and only travel along each edge once and only once.

Euler Circuit (ending at beginning node)
One can start at any node. All the nodes are of even degree. Click on the nodes below to traverse the graph. Clicking twice on a node will undo the last move.

Euler Path (traverse graph but not end up at the starting node)
Exactly two of the vertices are odd. One must start at one of the odd vertices and end up at the second one.

Not traversable or impossible 

One, three or more than three of the nodes are of odd degree.

NTFS Data Recovery - a very nice tool

I stumbled accross NTFS Data Recovery while trying to recover a PST file from MS Outlook. The file had been truncated to zero length after a system crash and I wanted to see if I could recover it. In the end, I didn't get the file back, mainly because I found a backup of the PST file and didn't need to it anymore; however, I must say that because of the generosity of LSoft Technologies Inc (http://www.file-recovery.com), which allows a free version to be dowloaded, I was able to learn a lot about file systems. In addition, the program came with some great reading material on how to recover files. In particular, a document  called "How to recover NTFS (Freeware Guide)", which can be found under the program's installed menu's item: "Documentation".

My use case was as follows:

Start Active@ File Recovery

Press the "Search" button in the menu bar's middle.

Enter the file format (*.pst), press "Find" and then navigate to the file using the explorer like view. From here, one can either inspect the MFT record or the raw data of the file.

When inspecting the file's data one should refer to Microsoft's documentation about PST files (Outlook Personal Folders (.pst) File Format). The formentioned document about file recovery contains some very helpful information about MFT records. 

Below, is the beginning of the raw data. Notice the marker "!BDN" at the beginning of the PST's header.

One thing, before starting your attemp to recover your lost file, I  would read the "How to recover NTFS (Freeware Guide)" first. There are some "Don'ts", like don't install any new software onto the same drive, you should read before starting.

Practical Tips and Tricks with Spring Integration (part one) attempted transcription of webinar

Learning Spring Integration by looking at  various messaging system XML configurations, in particular ones that make heavy usage of the namespace features, can be instructive but at the same time frustrating because one cannot easily develop a solid intuition about how the internals of the messaging system works. Looking at the underlying implementation often helps but can be somewhat discouraging as well because one often gets the feeling that one is trying to look at an elephant through a key hole because understanding code can be difficult if one doesn't know the intentions and thoughts of the developers who wrote the code.

What follows below are notes, or an attempted transcription, of the first few minutes of a Spring Pivotal Webinar from Oleg Zhurakousky called "Practical Tips and Tricks with Spring Integration", which I found incredibly helpful and full of amazing insights. Spring already has a lot of great documentation and probably doesn't need anymore, especially from someone who is an outsider, but while listening to the webinar for the first time, I realized that every sentence that Oleg said was packed with more meaning than I could absorb in real time. So I replayed it several hundred times and came up with the following crude copy of his explanations.

Error Handling related to messaging systems. 

2:42 

Message systems like any other system can produce errors. Very often the process of handling messages relies on messaging itself. The first example demonstrates this by showing how an error channel can be defined on the components, gateway and inbound adapters, which serve as entry points into a messaging flow.

3:07

At this point one should be clear of the distinction between components which serve as entry points into messaging flows, gateway and channel-adapters, and components which serve as message flow handlers within a flow; namely service-activators, transformers, filters, etc.

3:23 

A question which is often asked is: why isn’t there an error channel attribute on message flow handlers? An analogy which helps to understand this is that of exception handling where a messaging flow is equivalent to a Java block of code encapsulated by a try-catch block, where the try serves as an entry point into the block of code and each line of code within the try-catch is analogous to a message handler. An exception can happen anywhere within the try-catch block and when it happens, the "try" then delegates the flow to the catch block, which is essentially the error channel. Giving each message handler its own error channel attribute, or its own error handling routine, would be like supplying each statement within a try-catch block with its own try-catch, which would only complicate the picture.

4:21

Essentially components that serve as entry points into messaging flows are like try-catch blocks and also serve as components, which mark the boundaries or scopes of the messaging follows.  Error handling blocks of try-catch statements can be arranged right after each other, sequentially, or nested within each other to produce different behaviors. This can also be accomplished in a message flows as well and later it will be shown how to partition or segment message flows to accomplish that which we accomplished with traditional try-catch error handling.

4:56 Sample one.
The first configuration, sample, has a messaging gateway, which is our ErrorDemoGateway, and when we invoke the method on the gateway, the gateway sends the message to the inputChannel, which is a splitter, which splits the message and sends it to the processingChannel.  From the processChannel, the message is going to be processed by the filter and the filter is going to validate that the message's payload's length is greater than four. If it is, then it will be allowed to proceed and if not, it will raise an exception because of the attribute “throw-exception-on-rejection” is set to true. The successfully validated message will then go to the loggingChannel, which is basically a logging-channel-adapter, which will log the massage.

The explicit definition of the channel loggingChannel can be removed because it will be automatically created. Right now, our gateway does not define an error logging channel. So when we execute the code, we shall see that the exception gets caught in the caller’s code, which called the interface’s method.

To avoid that the caller has to deal with the exception and instead be gracefully informed that an error has occurred, we define a channel called “processErrorChannel” and point the gateway’s error-channel attribute to it. When an exception occurs the gateway will see that the error-channel attribute is explicitly define and will send the error message to the error channel to give the caller another chance to correct the message. In the transformer, which is subscribed to the error channel, the payload of the original message will be wrapped in hash tags to indicate that the message was in error.

Looking at the caller code, which gets the gateway from the application context and which calls its method with two strings, one which is too short, we can see from the logging output that one strings passes the filter and the other not by the presence of hash marks.
The exception is no longer propagated back to the caller as it was without the explicit definition of the error channel on the gateway.

8:56 Sample 2
Enterprise Integration Patterns (I assume the speaker was referring to the book) identifies several components, which are state full by nature and which may depend on a predetermined amount of messages coming in before some action would be taken. For example, you might have a flow with an aggregator, which expects three messages but if an error happens in the upstream processing, then the required amount of messages will never reach the aggregator and it in turn will never release the received messages.

10:07
However, by handling the error via a message flow, it is possible to send the message or some message describing the error to the aggregator thus satisfying the release requirements.
In the example, the message gets sent and is split before being sent onto the filter, which will only pass one of the messages onto the aggregator. The other one will be filtered out. This means that the aggregator will be holding onto one message and waiting for the other one, which will never come.

10:43
The application is demonstrated before being fixed, whereby the rejection exception is thrown but the application keeps running. The speaker then shows, using jconsole, that the aggregator has only processed one message. The application is then fixed by setting the gateway’s error-channel attribute to errorChannel.

13:34 Flow Segmentation and Flow Partitioning
Using the same try-catch analogy as we discussed at the beginning let’s look at a slightly different error handling requirement. Depending on the handler that generated the exception or result in the exception you may not want the exception to propagate back to the original entry point of the entire flow.

Using Java’s try-catch analogy it is as if you want to wrap part of the flow downstream in its own try-catch block. Basically, you want to create an independent flow partition or segment and to do this we shall use a technique that allows us to introduce a sub entry point within an existing messaging flow.

We do this by introducing a messaging gateway downstream, which is invoked by a service activator. So let’s look at how we do that. We do it actually quite simply. We have a gateway just like we had before (now called segmentOneGateway). We already have an error channel. This gateway, segmentOneGateway, identifies a request channel called segmentOneChannel, which has a subscriber that is a service activator, which is bootstrapped with a reference to a bean called segmentOne. The bean segementOne is actually another gateway, which is defined further downstream. The only difference here is that this gateway does not identify a service interface as it is no longer needed because it’s bootstrapped with the default interface. Once the service activator invokes the gateway segmentOne, it is as if someone else invoked a gateway and entered a sub partition or another messaging flow. This new flow is actually sitting within some parent messaging flow. We now have a service activator, which is being invoked by the second gateway, segmentOne, and if its throw and exception the exception will be send to it invoking gateway error channel, namely.

TBC

https://youtu.be/RY6dNUL8k6o?t=18

Configuring JavaMailSenderImpl for SSL as a Spring bean and with Spring Integration

Because my Window's Firewall blocked all outgoing requests on port 587, I had no option but to configure my JavaMailSenderImpl to use SSL instead of TLS. Below are the bean settings.

<beans:bean id="mailSender"
class="org.springframework.mail.javamail.JavaMailSenderImpl">
<beans:property name="username" value="your_mail@gmail.com" />
<beans:property name="password" value="your_mail" />
<beans:property name="protocol" value="smtp"/>
<beans:property name="port" value="465" />
<beans:property name="host" value="smtp.gmail.com" />
<beans:property name="javaMailProperties">
<beans:props>
 <beans:prop key="mail.smtp.ssl.enable">true</beans:prop>      
 <beans:prop key="mail.smtp.auth">true</beans:prop>    
         <beans:prop
                          key="mail.smtp.socketFactory.class">javax.net.ssl.SSLSocketFactory</beans:prop>
       <beans:prop key="mail.smtp.auth">true</beans:prop>
</beans:props>
</beans:property>
</beans:bean>


@Autowired
@Qualifier("mailSender")
private JavaMailSender javaMailSender;

@Override
public void sendAnmeldung(Message message) throws Exception {

    MimeMessage mimemsg = javaMailSender.createMimeMessage();   
    MimeMessageHelper helper = new MimeMessageHelper(mimemsg, true);
        
     helper.setTo("your_recipient@gmail.com");
     helper.setFrom("your_account@gmail.com");
     helper.setText(String.format("Javamail using spring JavaMailSender: %s",  Calendar.getInstance().getTime()));
     helper.setSubject("test email");

      this.javaMailSender.send(mimemsg);

}

The above settings can be used with Spring Integration's out-bound-channel-adapter as follows (of course the prefixes util and int-mail must be bound to their appropriate namespaces properly):

<util:properties id="javaMailProps">
<beans:prop key="mail.smtp.ssl.enable">true</beans:prop>      
<beans:prop key="mail.smtp.auth">true</beans:prop>    
<beans:prop key="mail.smtp.socketFactory.class">javax.net.ssl.SSLSocketFactory</beans:prop>
<beans:prop key="mail.smtp.auth">true</beans:prop>
</util:properties>
 
<int-mail:outbound-channel-adapter id="mails" 
host="smtp.gmail.com"
java-mail-properties="javaMailProps"
password="your_password"
port="465"
                username="your_username@gmail.com"/>

InstallShield's InstallScript debugger stops working

If you find that your InstallShield's (2014 Premier Version) InstallScript debugger unexpectedly stopped working, then check your MSI project's build settings (Build->Settings) and make sure that the MisExec.EXE Command-Line Argument's edit box is completely empty (As shown below).

After selecting various Log File Options, my debugger stopped working and it wasn't until I COMPLETELY cleared the options that it started working again.

STMP port 587 blocked by Windows firewall

Recently, I had problems trying to send emails using JavaMail and my Google gmail account. I read in many places that it was most likely my ISP provider, who was blocking my access to the service; however, I didn't believe it because I could send with the same java test program from a different computer within my network, an Apple with OSX, emails. The java test program I used for testing is given below and comes from the tutorialspoint website.

To see in my firewall protocol that the requests were being dropped, I had to first turn my firewall logging on which I did by opening up a command prompt with admin rights and executing the followng:

C:\>netsh advfirewall set allprofiles logging droppedconnections enable
Ok.

Then, I sent a request with the test program and saw in the logfile (%systemroot%\system32\LogFiles\Firewall\pfirewall.log) :

2015-09-27 09:28:37 DROP UDP 192.168.178.58 239.255.255.250 52323 1900 371 - - - - - - - RECEIVE
2015-09-27 09:28:37 DROP UDP 192.168.178.58 239.255.255.250 52323 1900 357 - - - - - - - RECEIVE
2015-09-27 09:34:12 DROP TCP 192.168.178.64 66.102.1.108 58144 587 0 - 0 0 0 - - - SEND

The test program threw the following exception:

>java -classpath .;mail.jar;activation.jar SendEmailUsingGMailSMTP
Exception in thread "main" java.lang.RuntimeException: javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com,
 port: 587;
  nested exception is:
        java.net.SocketException: Permission denied: connect
        at rewards.messaging.client.SendEmailUsingGMailSMTP.main(SendEmailUsingGMailSMTP.java:64)
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com, port: 587;
  nested exception is:
        java.net.SocketException: Permission denied: connect
        at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1972)
..
        at javax.mail.Transport.send(Transport.java:124)
Caused by: java.net.SocketException: Permission denied: connect

I should mention that with wireshark one will not see the requests because the requests don't make it beyond the firewall; however, if one clears the local DNS cache (C:\>ipconfig /flushdns), one can see with wireshark the hostname resolution request. This is nice because one can confirm that the destination address seen in the dropped TCP request is indeed the one associated with the program; the port number is also a good indication that one is looking at the correct request.  

Another useful tool was openssh, which I have installed on my Windows laptop because I'm using Git Bash. With openssl, I could get Google's x509 certificate using the following:

$openssl s_client -connect  smtp.gmail.com:465 -state -tls1

However, what didn't work was this:

$openssl s_client -connect  smtp.gmail.com:587 -state -tls1
Loading 'screen' into random state - done
connect: Bad file descriptor
connect:errno=10013

The dropped request was also logged accordingly in the firewall's protocol similarly to that shown above.

To trouble shoot, I took the following standard snippet of code taken from here:

import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.PasswordAuthentication;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

public class SendEmailUsingGMailSMTP {
   public static void main(String[] args) {
      // Recipient's email ID needs to be mentioned.
      String to = "xyz@gmail.com";//change accordingly

      // Sender's email ID needs to be mentioned
      String from = "abc@gmail.com";//change accordingly
      final String username = "abc";//change accordingly
      final String password = "*****";//change accordingly

      // Assuming you are sending email through relay.jangosmtp.net
      String host = "smtp.gmail.com";

      Properties props = new Properties();
      props.put("mail.smtp.auth", "true");
      props.put("mail.smtp.starttls.enable", "true");
      props.put("mail.smtp.host", host);
      props.put("mail.smtp.port", "587");

      // Get the Session object.
      Session session = Session.getInstance(props,
      new javax.mail.Authenticator() {
         protected PasswordAuthentication getPasswordAuthentication() {
            return new PasswordAuthentication(username, password);
         }
      });

      try {
         // Create a default MimeMessage object.
         Message message = new MimeMessage(session);

         // Set From: header field of the header.
         message.setFrom(new InternetAddress(from));

         // Set To: header field of the header.
         message.setRecipients(Message.RecipientType.TO,
         InternetAddress.parse(to));

         // Set Subject: header field
         message.setSubject("Testing Subject");

         // Now set the actual message
         message.setText("Hello, this is sample for to check send "
            + "email using JavaMailAPI ");

         // Send message
         Transport.send(message);

         System.out.println("Sent message successfully....");

      } catch (MessagingException e) {
            throw new RuntimeException(e);
      }
   }
}

weak ephemeral Diffie-Hellman tomcat6

After upgrading from SUSE 10 to SUSE 11, which encompassed an OpenSSL library upgrade, some HTTPS clients like chrome (Version 45.0.2454.85) or  wget started getting the following error "Server has a weak ephemeral Diffie-Hellman public".  No server changes on the server side, namely tomcat6, had been made.

Attempts to solve the problem by changing the sslEnabledProtocols or sslProtocol attributes of the Connector element in the server.xml shown below were unsuccessful. Also desperate actions such as updating the US_export_policy.jar and local_policy.jar did not help either.

The final solution was to limit the cipher suits by adding the ciphers attribute to the SSL enabled connector. See below

<!-- Define a SSL Coyote HTTP/1.1 Connector on port 443 -->

 <Connector port="443"  SSLEnabled="true"

            protocol="org.apache.coyote.http11.Http11Protocol"

             scheme="https" secure="true"

            clientAuth="want" sslProtocol="TLS"

     ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"

            keystoreFile="${catalina.base}/conf/%KEYSTORE%"

            keystoreType="JKS" keystorePass="%KEYSTOREPASS%"

            truststoreFile="${catalina.base}/conf/%TRUSTSTORE%"

            truststoreType="JKS" truststorePass="%KEYSTOREPASS%"

   />

Apache Tomcat's ciphers come from the under lying JVM, in particular the JSSE. To see which one are available put the following in a java main routine and run it.

/*******************************************/
StringBuilder sb = new StringBuilder();
try {
SSLParameters ssl  = SSLContext.getDefault().getSupportedSSLParameters();

sb.append("CipherSuites:\n");
for(String cs : ssl.getCipherSuites()){
sb.append(cs);
sb.append('\n');
}

sb.append("\nProtocols:\n");
for(String p : ssl.getProtocols()){
sb.append(p);
sb.append('\n');
}

} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}

return sb.toString();

/*******************************************/

The output should look something like this:

CipherSuites:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_KRB5_WITH_RC4_128_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5

Protocols:
SSLv2Hello
SSLv3
TLSv1