<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Drylm - Thoughts from the void. (Posts about devops)</title><link>https://blog.drylm.org/</link><description></description><atom:link href="https://blog.drylm.org/categories/cat_devops.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Sun, 28 Dec 2025 14:59:07 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>OpenLDAP + Blowfish hashes</title><link>https://blog.drylm.org/posts/openldap_blowfish/</link><dc:creator>Jonathan Muller</dc:creator><description>&lt;div&gt;&lt;p&gt;I have been recently faced to a problem regarding password encryption and support of the encryption in &lt;a href="https://www.openldap.org/"&gt;OpenLDAP&lt;/a&gt;. Working on an authentication project migration, we have passwords encrypted using &lt;a href="https://en.wikipedia.org/wiki/Blowfish_(cipher)"&gt;Blowfish&lt;/a&gt;, we have to migrate them under OpenLdap.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://blog.drylm.org/posts/openldap_blowfish/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>blowfish</category><category>openldap</category><guid>https://blog.drylm.org/posts/openldap_blowfish/</guid><pubDate>Fri, 22 Mar 2019 23:57:03 GMT</pubDate></item><item><title>Rabbitmq and Erlang/OTP Windows Containers</title><link>https://blog.drylm.org/posts/rabbitmq_windows_container/</link><dc:creator>Jonathan Muller</dc:creator><description>&lt;div&gt;&lt;p&gt;Here at &lt;a href="http://www.gsx.com"&gt;Gsx Solutions&lt;/a&gt; for our full product suite, we highly rely on &lt;a href="https://www.rabbitmq.com/"&gt;RabbitMQ&lt;/a&gt;. Until last release we rely on version 3.5.4 we delivered to our customers. Since, this version has been recently been deprecated, we decided to upgrade our final package to &lt;a href="https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.7.4"&gt;v3.7.4&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://blog.drylm.org/posts/rabbitmq_windows_container/"&gt;Read more…&lt;/a&gt; (5 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>.net</category><category>docker</category><category>dockerfile</category><category>erlang</category><category>multi stages build</category><category>powershell</category><category>rabbitmq</category><guid>https://blog.drylm.org/posts/rabbitmq_windows_container/</guid><pubDate>Tue, 29 May 2018 18:49:32 GMT</pubDate></item><item><title>Debug dotnet applications inside a docker container</title><link>https://blog.drylm.org/posts/debug-dotnet-applications-inside-a-docker-container/</link><dc:creator>Jonathan Muller</dc:creator><description>&lt;div&gt;&lt;p&gt;From time to time, as a dotnet developer we have to face this specific error &lt;strong&gt;Could not load file or assembly 'Assembly Strong Name' or one of its dependencies&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;To help debugging this particular situation, Microsoft provides a tool in the .net SDK called: &lt;em&gt;fuslogvw&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://blog.drylm.org/posts/debug-dotnet-applications-inside-a-docker-container/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>.net</category><category>c#</category><category>csharp</category><category>docker</category><category>fuslogvw</category><category>powershell</category><guid>https://blog.drylm.org/posts/debug-dotnet-applications-inside-a-docker-container/</guid><pubDate>Sat, 10 Feb 2018 09:26:25 GMT</pubDate></item></channel></rss>