Managing your gmail mailbox

I found out a way to get full control of my heavily loaded gmail mailbox… just plain code…without complicated looking (not easy to find) user menu’s to configure settings for archiving and cleaning my mailbox. Login to your gmail account (with your browser)…and then go to

Here you can put your (javascript) code and even debug it. Even better…after you are finished, you can expose this code as a (web)service or schedule it with the built in timer, woa …excellent dude!!!

Here is a snippet of the code I am using:


function cleanUp() {
var delayDays = 0; // Enter # of days before messages are moved to trash
var maxDate = new Date();
cleanupCandidates = ["","","","[email protected]","[email protected]","","","","","","","","","","","autodna.mail"];

gthreads = GmailApp.getInboxThreads();
for (var fc=0; fc<cleanupCandidates.length; fc++){
for (var i=0; i<gthreads.length; i++){
messages = gthreads[i].getMessages();
for (var j=0; j<messages.length; j++){
if (messages[j].getDate()<=maxDate){
Logger.log("Message older than maxdate ("+delayDays+"days)…removing it: ");
Logger.log("THREAD ID"+gthreads[i].getId()+" FROM: "+messages[j].getFrom()+" subject: "+messages[j].getSubject());

function labelStuff(){
archiveCandidates = ["","[email protected]","","","","","","","","","","Niels Westmeijer <[email protected]>"];
labelCandidate = ["Archief/eve","Archief/playstore","Archief/microsoft","Archief/reizen","Archief/redhat","Archief/hosting","Archief/hosting-sec","Archief/hosting-sec","Archief","Archief","Archief/iTunes","Archief/eve"];

gthreads = GmailApp.getInboxThreads();
for (var i=0; i<gthreads.length; i++){
messages = gthreads[i].getMessages();
for (var j=0; j<messages.length; j++){
Logger.log("Evaluating message frpm: "+fromMail);
Logger.log("Found at:"+foundAtLocation+" Applying label "+label+" for: THREAD ID"+gthreads[i].getId()+" FROM: "+from+" subject: "+messages[j].getSubject());
eveLabel = GmailApp.createLabel(label);


here a screeshot:

Schermafbeelding 2016 02 15 om 21 52 35

screenshot of the trigger/ scheduler…cronjob editor


picketlink implementation notes for websphere

Schermafbeelding 2016 01 28 om 08 44 08

Flow in a nutshell

User acces the application

  • The default deployment descriptor will state that this is a protected resource and needs to be handled by its container
  • The application does its security stuff within the context of websphere security domain, within this domain it is configured to make access to this application only available via a TAI (Trusted Authentication Interceptor)
  • The TAI is configured that authentication errors (which is the case if you access the application the 1st time) should be redirected to the IDP, the TAI makes sure that an authentication (LTPA) cookie is also set:
  • We have configured a SP which an SAML authentication request and sends the request to the IDP
  • The IDP will authenticate and create a SAML token, however due to problems with Websphere accepting the SAML token we had to write a custom Authentication Handler that generates the SAML token according to Websphere standards
  • The IDP redirect to the Assertion Consumer Provider which is basically a webapp which is deployed on Websphere
  • The ACS checks if the SAML token is correct and uses the username from the token to check if the user exists in it’s local LDAP The IDP contains also a X509 certificate which is used as a identifier…this certificate is used by the ACS to check if the certificate is trusted
  • After all ACS checks (X509 check/ SAML token and LDAP check) have been verified, the user is allowed to access the application
  • The ACS uses the Cookie in order to redirect to the appropriate APP, the name of the cookie is: WasSamlSPReqURL  
The Picketlink Authentication HandlerIn order to implement this handler, we have added a module in JBoss with the following config:

<?xml version="1.0" encoding="UTF 8"?> 
<module xmlns="urn:jboss:module:1.1" name=“companyhandler">
<resource root path="idp idp handler 2.1.8.Final.jar"/>
 <module name="org.picketlink"/>
 <module name="org.picketlink.config"/>
<module name="org.picketlink.federation"/>
<module name="org.picketlink.common"/>
<module name="javax.api"/>
 <module name="javax.servlet.api"/>
<module name="org.picketbox"/>
The main part is in the companySAML2AuthenticationHandler which is an extension of SAML2AuthenticationHandler…this handle overrides the handleRequestType method….basically it does the same…but in order for Websphere to accept this token it needs to get rid of the InResponseTo attribute…

The following code snippet was added:

Document samlResponse = this.getResponse(request); 
Node entries = samlResponse.getFirstChild();
NamedNodeMap nnm = entries.getAttributes();
NodeList nList = samlResponse.getElementsByTagName("saml:SubjectConfirmationData"); 
for (int temp = 0; temp < nList.getLength(); temp++) {
Node nNode = nList.item(temp);
Element eElement = (Element) nNode; nnm = eElement.getAttributes();

The code is called in the IDP by configuring the following in the webapp/WEB INF/picketlink.xml file

<Handlers xmlns="urn:picketlink:identity federation:handler:config:2.1">
<Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" />
<Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" />
<Handler class="" />
<Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" />
<Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureValidationHandler" />

<! The following was commented out… replaced by the

<Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" />

The Websphere TAI only accepts keys from trusted parties…in the IBM documentation it is stated how to configure the keystore… We made ourselves known to Websphere (The TAI is accepting communication with us) by doing the following:

Created our own keystore:

keytool genkey validity 10000 alias HOSTNAME keyalg RSA keysize 1024 dname "CN=HOSTNAME, O=Company, C=ES” keypass PASSWORD keystore identity.jks storepass PASSWORD

Then we added the keystore to Websphere and make the TAI accept certificates from this keystore
Then we needed to extract the X509 certificate for the alias we are going to use: 

keytool export keystore lnxwaslr18.jks rfc alias lnxwaslr18 

This will give you something like this:


You will need to add the following section in your resources/idp metadata.xml file:

<EntitiesDescriptor Name="urn:mace:shibboleth:testshib:two" ..
<EntityDescriptor entityID="http://lnxwaslr18:8080/idp metadata">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<dsig:KeyInfo xmlns:dsig=""> <dsig:X509Data>
ChMHQWxsaWFuejETMBEGA1UEAxMKbG54d2FzbHIxODAeFw0xNTEwMDUxNDQ2MTRaFw00MzAyMjAx NDQ2MTRaMDQxCzAJBgNVBAYTAkVTMRAwDgYDVQQKEwdBbGxpYW56MRMwEQYDVQQDEwpsbnh3YXNscjE4MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqkra4ZxEwExGCb5gerZWEF+dK+iCJag+A z5PIkB/2BP9UP4AomknT93y2czthCDtplzeLGN15UMiURBzdxNtwnMHCr4xku2sFOyuNs7W0yWZ3 9o7Hn1TKvwDfczillKuTF+okP4OllM9mXN5gmietiSrlIwT2kIlzaNAv0MsGHQIDAQABoyEwHzAd BgNVHQ4EFgQUNCK2/WUY51kVN7kyqHU/N4XaH/8wDQYJKoZIhvcNAQELBQADgYEAFUb/efGbZDxq rSw7u6e9j4txbHf+VqtZrVEVkm+r3cNai9vIs7jNzixgaoC6W5kE5x1wtYpkdNjH9EY7SdDFS9EP 7Wt+NI2EdAA3Op50iHjdXiJ5ESHtYNQOFEiTX8+8JglSOAUKacNSdWv0LOm/Ga2GuRe/5LXVfmi5 z+eaIIs=
</dsig:X509Certificate> </dsig:X509Data>
</dsig:KeyInfo> </KeyDescriptor>

NB: Only the cursive part

Websphereconfiguration is according to these documents: https://www https://www https://www administration/step step guide implement saml 2 0 portal 8 5/

Picketlink configuration

playing with jboss eap and mod_cluster

There are many good articles available on how to configure mod_cluster for jboss eap…some really good ones:

There is even a tool which can help you configure the optimal settings:

Although there is good literature about this topic, it took me a while to make things work…there are so many pitfalls and possibilities, for eg I spent quite some time configuring wildfly9 and I got this error…MODCLUSTER000042, eventually you get redirected to supported configuration schema’s, you are downloading libraries which seem to be unfindable at first…and before you know it ..half a day is gone.

As I am a lazy bastard…I just want one docker image that does it all, and figure it out later:

  • install 2 jboss instances
  • configure the mod_cluster part on the instances
  • deploy a webapplication on it, which shows you on which server you are
  • put an apache instance in front of it
  • configure mod_cluster to point to one of the jboss instances

I made a docker image available that could save you that half a day, instructions:

  • docker pull cvugrinec/jbosseap63-cluster-withapp:1.4
  • docker run -d -p 8666:80 -p 6666:6666 cvugrinec/jbosseap63-cluster-withapp:1.4
  • if you are on windows or mac and you are using docker-machine, make sure you are port-forwarding the following: 8666 to 8666 and 6666 to 6666
  • then go to your browser and see the mod_cluster config: http://localhost:6666/mod_cluster-manager
  • check the web app with: http://localhost:8666/rws_javaClassicDemo/
  • if you like to tinker with it…just do the docker run -it <pid of docker> bash …and play around in the /opt folder…there you find all the scripts used, config in /etc/httpd/conf.d/jboss.conf, /opt/jboss_instances/instance1/configuration/standalone-ha.xml and /opt/jboss_instances/instance2/configuration/standalone-ha.xml
  • you can find the root password in /README.txt
If you are testing, please note that this is not a simple round robin implementation (you will not be switched from instance with every refresh)
try killing the instance you reside on…refresh and see what happens 


rollout jenkins with puppet (ver 4.2)

My notes for creating the puppet module for rolling out jenkins.

create a module template with the build in wizzard

puppet module generate [username]-[name of module]

for e.g.

puppet module generate cvugrinec-jenkins 

After you follow the wizzard (you can (if you like) follow the default values) you will have a module template in the following directory:


your starting point from here will be:

/etc/puppetlabs/code/environments/production/modules/[name of module]/manifest/init.pp

for e.g.


Assuming the example: the content of this file will be initially:

# a lot of comments
class jenkins{

In this piece you can add puppet code like:

case $::osfamily { 
'Redhat': {
$msg = "OS on hostname: $hostname is supported, starting install:"
notify{ $msg: }
default: {
$msg = " on hostname: $hostname is NOT supported, exiting"
fail("${::osfamily} ${msg}")

if you like your module to use submodules you can define a subclass.
In the /etc/puppetlabs/code/environments/production/modules/[ module name] /manifest/  directory create a file for e.g. someSuperDuperModule.pp
and define some skeleton code:

class jenkins::someSuperDuperModule{

After doing this you need to include this in your init.pp with the following line:

include jenkins::someSuperDuperModule

Ok so far you have a module but this is quite useless …besides the empty code, you like to have this code run on a puppet client….where is all the puppet magic???
One way to realize this is using meta data….
when the puppetclient runs on a pre scheduled time, it will make a call to the puppetmaster the puppetmaster can discriminate based on the meta data from the client what classes need to be executed on the client.

when the client connects to the puppetmaster the main entry point will be:


there you can configure an entry like this:

node “someSuperDuperHostname.local” {
  class { “jenkins" : }

This will execute the jenkins module on the client with hostname: someSuperDuperHostname.local

Next to this you can use hiera for key value lookups…this is very powerfull if you would like to use values in your script.

in the /etc/puppetlabs/code/environments/production/manifest/site.pp you can define this line:


this will evaluate the /etc/puppetlabs/code/environments/production/hieradata/common.yaml , it should contains something like this:

- jenkins

it will load the jenkins module according to the config of this file /etc/puppetlabs/code/hiera.yaml:

  - yaml
  :datadir: /etc/puppetlabs/code/environments/production/hieradata
  - "node/%{::fqdn}”
  - common

here you tell that in the /etc/puppetlabs/code/environments/production/hieradata directory there will be a node subdirectory that will contain filenames which will have the name of the hostname of the (puppet) client. The filename will have a .yaml extension. If your puppetclient resides on someSuperDuperHostname.local then the meta data file that will be evaluated for this host will be:

if you have this property configured in your node/someSuperDuperHostname.local.yaml file:

  version: 1.642 

you can test if a value is properly configured with this command:

hiera jenkins.version ::fqdn=someSuperDuperHostname.local

this will return 1.642

So when you are done configuring lets do something and test if the puppetclient loads the desired module:

in the module write some hello world code like this:

class jenkins {
$msg = "HELLO WORLD"
notify{ $msg: } 

On your client test your code with the following command:

puppet agent -t

you will see something like this:


weak GMS signal

I am living in an area where my reception of my mobile phone sucks….

First I wanted to understand where I can find the strongest GSM signal in my village, so I looked up the “GSM Masten” available in my village

Then you need to know which one you will need…I have VodaFone…so search the “GSM Mast” with the frequency for Vodafone, you can lookup the frequencies with this wonderful site….it also helps you to understand frequencies and cellular technology in general :

this page shows a table with frequencies that Dutch cellular providers have:


Schermafbeelding 2015 08 27 om 23 20 35


you can buy a GSM repeater …a GSM signal amplifier on the following sites:

Cell Info on your iphone:
Imei information on your phone

adding multiple java exception lines as 1 message in elasticsearch

There are many ways that lead to Rome, meaning (in this context) that there are many solutions for the question:

“adding multiple java exception lines as 1 message in elastic search”

My solution is adding the following “GROK” filter to my log stash config:

filter {

   multiline {
      pattern => “^[\[\tat] %{GREEDYDATA:DATA}”
      negate => true
      what => “previous”

This expressions says that every line starting with (from the beginning of the line (^) ) a tab (\t) and the word at is adding to the previous line…
this the case when you have a stacktrace, for e.g:

Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "UK_9QV6YHJQM8IAFTO8QK452GX8H_INDEX_8 ON PUBLIC.MEMBER(EMAIL)"; SQL statement:
insert into Member (email, name, phone_number, id) values (?, ?, ?, ?) [23505-168]
at org.h2.message.DbException.getJdbcSQLException(
at org.h2.message.DbException.get(
at org.h2.message.DbException.get(
at org.h2.index.BaseIndex.getDuplicateKeyException(
at org.h2.index.TreeIndex.add(
at org.h2.table.RegularTable.addRow(
at org.h2.command.dml.Insert.insertRows(
at org.h2.command.dml.Insert.update(
at org.h2.command.CommandContainer.update(
at org.h2.command.Command.executeUpdate(
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(
at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate( [hibernate-core-4.2.14.SP1-redhat-1.jar:4.2.14.SP1-redhat-1]


Adding LDAP Authentication for JBoss EAP 6

A while ago I scribbled a piece about authentication with ldap on Weblogic, see:

This article does the same for JBoss EAP 6.0. I am using apacheDS as opensource ldap server…
In the article mentioned earlier it shows you how to setup apacheDS (great tool 🙂 and how to create a ldap user…if you have another ldap server that contains your users…you can make an export of a user(s)…and import the ldiff file with the following command:

ldapmodify -h localhost -p 10389 -D “uid=admin,ou=system” -w secret -a -f someExportedLdifFilename.ldif

the command above contains the default values for the apachDS installation…

Configure JBOSS by adding the following sections to your config (default = standalone.xml )



        <security-realm name=”TestRealm”>
              <ldap connection=”ldap_connection” base-dn=”ou=users,ou=system”>
                 <username-filter attribute=”uid” />




          <native-interface security-realm=”TestRealm”>
             <socket-binding native=”management-native”/>
          <http-interface security-realm=”TestRealm”>
             <socket-binding http=”management-http”/>


         <ldap name=”ldap_connection” url=”ldap://″ search-dn=”uid=admin,ou=system” search-credential=”secret” />


What you just did is defining in the management section a REALM (a collection of users)  and making sure that the interfaces for MGMT communication are using this newly defined security realm.