My sonatype-nexus-openshift repository is now able to deploy Nexus 3.x. You can check the README.md file to see how to do it.
As the scripts will change the JVM memory configuration, it is possible to run Nexus 3.x on small gears.
Please keep in mind that at this moment is not possible to migrate Nexus 2.x to Nexus 3.x, so I suggest you deploy to a new cartbrige.
The biggest problem with sending email from AWS EC2 instances is that -sooner or later- your instance’s IP will be added to a blacklist. It doesn’t matter how secure your MTA is. It doesn’t matter if it’s not reachable from the internet. And it doesn’t matter if you are not sending spam at all.
Sooner or later one of your neighbors using an IP on the same IP range your instance is, will send spam, Then one of the blacklists (such as Trendmicro’s) will add the whole range as spam sender.
In theory you could try setting up rDNS but that’s not always a warranty of staying out of the lists. And obviously what AWS recommends is using (and paying) Simple Email Service or SES. It’s pretty easy to setup and pretty easy to use (you can setup IAM accounts to use SMTP).
For some services the configuration will be easy: add the SES endpoint as SMTP server hostname, enable SSL, select TCP port 465, add your credentials, and ready to go.
But how to do it for Nagios or Icinga (version 1)? (more…)
For the last two years, I was using Shekhar Gulati GitHub repository to manage my personal Sonatype Nexus service. Deploying to OpenShift was easy, and I could get Nexus running in less than five minutes.
However, this repository was using Nexus as a war file in Tomcat, something which is now deprecated by Sonatype, and won’t be provided for the upcoming 3.0 release. Besides that, the war doesn’t include support for NPM or Ruby gems, and uploading new war files to the repository was slow and inefficient.
Usually you have several options when you want to backup PostgreSQL instances. First stop would be the offical doc. But at some point dumping data, or stopping the instance would not be enough. Of course, you could also go for the incremental backups using the Write Ahead Log (WAL).
But what if you want fast backups, with fast recovery, and your instance is really huge? (more…)
NOTE: ebs-changer is no longer maintained, as is now included into EBS-Tools suite
Did you ever want to change standard EBS to io1 volumes on Amazon Web Services? Maybe io1 to standard? Did you want to increase the number of PIOPs your volumes are using? Did you performed this tedious job by hand?
In my current project (SmartSteps) at Telefonica R&D we needed to to this a lot of times on several environments using MongoDB replicasets and RAID0 on each mongo server.
So each time we needed to stop mongo services (or the instances), snapshot all the volumes, detach, delete old volumes, create new volumes from the snapshots and then reattach them using the same devices. That was more than 15 times the same set of operations.
And of course, it was likely possible to make mistakes in the process.
So, why should we do this by hand when it’s possible to automate and run the changes in parallel? (more…)
Copyright © 2024 | WordPress Theme by MH Themes