(Everyday DevOps and Infrastructure – instead of keeping the knowledge in our team, let’s share it with the community)
Today we again got reminded that what you’ve configured in ufw is not what actually happening.
ufw is wrapping iptables. The rules that you seen in ufw are not really the rules that are applied for the firewall. They could be different. They could be a lot different.
To get the complete rules you should check
$ iptables --list
Then you should flush the iptables and start from zero and recreate the rules of ufw. Of course, backup the rules if anything goes wrong, but ufw is not the actually firewall. It just helps you manage your iptables.
I think there should be some kind of notification when opening ufw status where it should tell you that iptables rules are different from the ufw status rules. This could increase quality of life and general security on the internet.
(Everyday DevOps and Infrastructure – instead of keeping the knowledge insider of our organization let’s share it with the world)
We: – Today it will be a great day
The god of computers: – I don’t think so. Here is something for you
App 1558233 output: Error: The application encountered the following error: libssl.so.1.0.0: cannot open shared object file: No such file or
directory - /usr/....path.../x86_64-linux/openssl.so (LoadError)
Why it happened?
We did
$ sudo apt get upgrade
$ suod autoremove
Nothing of importance to see there and we went about with doing the autorremove. But it turns out autoremove has removed libssl. Why? I don’t know. I guess that because it has 1.1 it will automatically remove 1.0.0. But
How we fixed it?
# As we can see there is not libssl.so.1.0.0
kmitov@vpszap6s:/usr$ sudo find . -name libssl.so*
./lib/x86_64-linux-gnu/libssl.so
./lib/x86_64-linux-gnu/libssl.so.1.1
# So we install it
$ sudo apt-get install libssl1.0.0
# And now there is
$ sudo find . -name libssl.so*
./lib/x86_64-linux-gnu/libssl.so
./lib/x86_64-linux-gnu/libssl.so.1.0.0
./lib/x86_64-linux-gnu/libssl.so.1.1
(Everyday Code – instead of keeping our knowledge in a README.md let’s share it with the internet)
Today many things stopped in our dev procedures and I had to learn about heroku auth:whoami and to use it. Luckily, nothing about production, but a few engineers were puzzled as to why certain dev services are not working.
Heroku CLI logged itself out
We are using Heroku CLI a lot for a lot of different things. One example is backups. We backup the Heroku DBs regularly – like Daily, Weekly, Monthly and some of the backups stopped working. A few other services also stopped working. The problem was with Heroku CLI. The direct log from our Jenkins was:
heroku: Press any key to open up the browser to login or q to exit: ▸ Invalid credentials provided.
Enter your Heroku credentials:
Strange. It was working for years and now suddenly heroku cli decides to log itself out and it then requires us to log in. How come, we don’t know. I’ve created a Ticket with Heroku. My greatest concern is that it could be a security issue with someone gaining access to a dev machine and logging out, but I have no evidence of this.
$ heroku auth:whoami
I had to log in again with heroku. But I also wanted the builds that were ran with Jenkins to fail if heroku cli is not logged in. I found the command:
$ heroku auth:whoami
Which does the job. If we are not logged in the command will return and the bash script will fail.
Same applies for wget. There are tools that always work. Because they do one thing and they do it well. Not that there are no version. There are. But today was the first time in my career that we had to upgrade a wget version. We moved from version 1.17 to 1.20
Why the change
What could have changed that made it important to update from 1.17 to 1.20?
It was the introduction of support of some mandarin symbols. Mandarin. A language. Users were uploading files names with such symbols and we had to support them.
This article is part of the series [Everyday Code]
You’ve done nothing until you release more than 99 versions of your product. 99 versions are just not good enough.
TL;DR;
Today we released version 103 of is-core – the core of the Instruction Steps Framework. We noticed a bug. Generally the build would produce two files:
is-core-sdk-6.0.0.pre.103.js - that is the current version
is-core-sdk-latest.js - this is pointing to the content of the latest version.
Problem was that while the current version was 103, the latest version in is-core-sdk-latest.js was pointing to version is-core-sdk-6.0.0.pre.99.js.
As a conclusion – You have done nothing until you’ve released at least 100 versions of your software (and probably at least it works through a millennium shift with a leap year, but that’s another story)
Details
It’s pretty simple actually. This is what we were doing to get the latest file generated:
# Creates is-core-sdk-latest.js link to the latest compiled
cd ../../release
rm is-core-sdk-latest.js -f
-latest=`find is-core-sdk-* -type f | tail -1`
+latest=`ls -1v is-core-sdk* | tail -1`
echo "Latest sdk is: $latest"
Notice the find is-core-sdk-* -type f | tail -1 If the files are like
# Find all the files but they are listed in non natural order of the integer for the version.
# This code is: BAD
$ find is-core-sdk-* -type f
is-core-sdk-6.0.0.pre.102.js
is-core-sdk-6.0.0.pre.103.js
is-core-sdk-6.0.0.pre.97.js
is-core-sdk-6.0.0.pre.98.js
# If we get just the tail it will give us version 99 which is clearly not right
$ find is-core-sdk-* -type f | tail -1
is-core-sdk-6.0.0.pre.99.js
I have done this mistake at least a few times in my career.
Solution is an option in ls:
# This code is GOOD
# This will list all the files
$ ls -1v is-core-sdk*
is-core-sdk-6.0.0.pre.97.js
is-core-sdk-6.0.0.pre.98.js
is-core-sdk-6.0.0.pre.102.js
is-core-sdk-6.0.0.pre.103.js
# This will get just the last
$ ls -1v is-core-sdk* | tail -1
is-core-sdk-6.0.0.pre.103.js
Moral of the story
For months I thougth we have a rock solid infrastructure. There was almost no failed build. Delivery to production is in 2 minutes for a pretty complex framework with a lot of projects and modules. And then it “broke” after months of stable work just as we were to release version 100.
Show me your 100-th version of your product. Then we can talk.
Reply
You must be logged in to post a comment.