Tagged: linux Toggle Comment Threads | Keyboard Shortcuts

  • kmitov 6:46 am on March 26, 2021 Permalink |
    Tags: iptables, linux, ufw   

    ufw is not blocking traffic the way you think it is? 

    (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.

  • kmitov 6:32 am on March 26, 2021 Permalink |
    Tags: , linux   

    libssl.so.1.0.0: cannot open shared object file: 

    (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*
    # So we install it
    $ sudo apt-get install libssl1.0.0
    # And now there is
    $ sudo find . -name libssl.so*

  • kmitov 7:06 am on February 3, 2021 Permalink |
    Tags: , , linux   

    $ heroku whoami? 

    (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.

    We are happy again

    This instruction is delivered with heroku 🙂

    FabBRIX Pets, Hamster in 3D building instructions
  • kmitov 4:25 pm on October 23, 2020 Permalink |
    Tags: linux, mandarin, utf, wget   

    "wget 1.20 is here!" (never in my life I though I'd say that) 

    (this particle is part of the Everyday Code series)

    There are tools that just work. Low level tolls doing much of the heavy lifting and one thing you know about them is that they work. You never write

    $ mv --version source target

    For that matter you also never write

    $ cp -- version 1.3 source target
    $ ssh --version 1.2.1 use@machine
    $ curl --version 773.2  url

    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.

    The internet. What a beautiful place.

  • kmitov 10:45 am on April 3, 2020 Permalink |
    Tags: , , linux   

    99 versions are not good enough – [Everyday Code] 

    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.


    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)


    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 
    # 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

    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*
    # This will get just the last
    $ ls -1v is-core-sdk* | tail -1

    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.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc