Friday 26 June 2015

Delete files that are x days old

Sometimes in Linux, you want to clear out older files in a directory. One instance would be if you have a security system and it continuously writes video files to a directory on your NAS (Network Attached Storage) until it fills it up. You’ve figured out that if you keep a week’s worth of video, it will usually leave plenty of space for other users.

What I would suggest here is creating a cron job that runs every night and runs something like the following command:
What it all means:
find: the command that will search for the files
/path/to/files/: the top level directory to start searching
-type f: so we don’t remove directories, only files
-mtime +7: files older than ‘7’ days. Change to ‘+14′ to delete files older than 2 weeks.
-exec: what to do with the files we find
rm -rf: remove them recursively, force
{}: this represents each file we find
\;: the end of the exec
SO – the crontab entry would be this:
This will run every night at 2am.

Thursday 25 June 2015

SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection

Error:


[4/10/15 10:44:20:024 EDT] 00000067 SSLHandshakeE E   SSLC0008E: Unable to initialize SSL connection.  Unauthorized access was denied or security settings have expired.  Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
        at com.ibm.jsse2.K.B(K.java:141)
        at com.ibm.jsse2.SSLEngineImpl.b(SSLEngineImpl.java:106)
        at com.ibm.jsse2.SSLEngineImpl.c(SSLEngineImpl.java:184)
        at com.ibm.jsse2.SSLEngineImpl.wrap(SSLEngineImpl.java:582)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:16)
        at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:746)
        at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:566)
        at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:295)
        at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
        at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:558)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:608)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:985)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1074)
        at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported

Cause :


While Searching for this error I came across very important and helpful information. Here we consider that you all aware of the  SSL Handshake term or we will discuss it in brief later. In SSL hand shake the two communicators i.e. client and server initiate connection with each other to perform the transaction. For handshake we are having a different protocols based upon client and server. There is condition that for handshake need the communication protocols on both side should be compatible. Here in case WebSphere application server is our server and the requesting client may be different. It may be Webserver or your java application or you web browser or any internal service.

Here consider in my case the client which is asking foe handshake is a java application. Almost all HTTPS requesting traffic from application is Java generated. So the protocol requested by my java application is not enabled on server side so it's not supporting the handshake.

Let's check the below table for more clarification.



Here in my case the application is running using the java 6 means it will support the minimum SSLv3** and Maximum TSLv1 Version. Here in case if I disable the SSLv3** support from my server side the my application will use the higher version of SSL to handshake and will establish the connection for transaction. But I disable the higher version i.e. TSLv1 then it is not possible to establish the hand shake. So it will show the error Client requested protocol TLSv1 not enabled or not supported. Same thin will happen vise versa .

Solution:


In such case you can go and check on Websphere application server console which version of SSL handshake protocol your server is supporting. For that go to the
SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings (your Custom setting ) > Quality of protection (QoP) settings and check. Here in my case it was showing TLSv1.2 which is not supported by a client.



So here I go and set the protocol to TLSv1, which one client asking for. And now it's working fine.



For this click on the drop box, select the suitable protocol, Apply the change and don't forget to save it.