Sardarji in bar

_*This joke apparently won an award for the best joke in a competition held in Britain*_ _*Mr Singh walks into a bar in London , orders 3 glasses of beer and sits in the backyard of the room, drinking a sip out of each one in turn.*_

_*When he finishes, he comes back to the bar counter and orders 3 more. The bartender asks him, “You know, beer goes flat after I fill it in the glass; it would taste better if you buy one at a time.”*_

_*Mr. Singh replies, “Well, you see, I have two brothers. One is in Dubai , the other in Canada and I’m here in London . When they left home, we promised that we’ll drink this way to remember the days when we drank together.”*_

_*The bartender admits this is a nice custom and leaves it there.*_

_*Mr. Singh became a regular in the bar and would always drink the same way. He’d order 3 Beers and drink them in turn.*_

_*One day, he came in and ordered only 2 Beers. All the other regulars notice and fall silent.*_

_*When he comes back to the bar for the second round, the bar tender says, “I don’t want to intrude on your grief, but I wanted to offer my sincere condolences on your great loss.”*_

.

.

.

_*Mr. Singh looked confused for a moment, and then he laughs…. “Oh, no,”*_
_*He said, “Everyone’s fine; both my brothers are alive. The only thing is…*_
_*I have quit drinking”!!!*_
😄😄Try Beating this 😜

Modifying owner of a file on Mac

The chown command allows one to change the owner of a file. If you can’t run the command due to insufficient privileges, another way to change the owner is through Finder – this also requires elevated privileges. Here are the steps on how to do it from Finder:

Step 1: Open Finder and from the Menu click on Go -> Go to Folder…

Step 2: Select the file then from the Menu click on File -> Get Info

Step 3: Click on the lock icon at bottom right to unlock. This step requires elevated privileges. Screenshot below:

Now you can edit ownership and permissions. Adding this line to the sudoers file will give you same privileges as root on your machine:

<your-user-name> ALL = (ALL) ALL

Azure Pipeline gets stuck in Queued state

Background & Assumptions: This post assumes you know how to install an azagent on your VM and applies to self-hosted agents on Linux VMs. See this for how to install a self-hosted agent on Linux VM. The azagent runs as a service on your Linux VM and pulls jobs from Azure Devops to be executed. Note the agent pulls jobs. Jobs are not pushed to the agent. The diagnostic logs of the agent can be found under the _diag directory of the agent’s root folder. Further the post is specific to a pipeline that used to work, but will stop running after a while. If your pipeline does not work to begin with, chances are you have some other problem with it. E.g., this bit me when I wrote my first pipeline and took quite a while to figure out.

From time to time your azure pipeline will get stuck in Queued state and eventually time out after 1 hour.

You can try checking the logs but they will be empty. You can try stopping and restarting the agent, but no luck. If you contact Microsoft you will get a canned response from them saying this happens because you exceeded your quota of max parallel jobs which is BS. And they will pester you for logs and ask to re-run the pipeline with System.Debug:true. You do all this but they still can’t resolve the issue. The reality is that they are clueless. The only known fix (AFAIK) to this problem is to uninstall and re-install the agent again. You can do this by following below steps (all run as root user):

Step 1: Stop the agent

#-> ./svc.sh stop

Step 2: Uninstall the agent

#-> ./svc.sh uninstall

Step 3: Obtain a new PAT you will need to unregister the agent

You obtain this from following screen that you must have used earlier when you setup your agent. (Tip: Removing the agent from Azure Devops UI will not work. You will get errors in next step.)

Step 4: Unregister the agent

#-> AGENT_ALLOW_RUNASROOT=true ./config.sh remove

You will be prompted for PAT. Provide it the PAT from previous step.

Step 5: Reinstall the agent

Do this using the same steps that you followed to provision your original agent. The commands should look like following where you substitute PAT and other strings as appropriate

AGENT_ALLOW_RUNASROOT=true ./config.sh --environment --environmentname "QA" --acceptteeeula --agent $HOSTNAME --url https://dev.azure.com/myorganization/ --work _work --projectname 'myproject' --auth PAT --token mytoken --runasservice
./svc.sh install
./svc.sh start

Now the pipeline should work again.

Where are the Logs?

TL;DR: When running WordPress inside a container based on the wordpress:php7.4-fpm-alpine image, docker logs will only show you the system logs. Your own log messages i.e., the messages you output in your application using the error_log function will appear in the WP_DEBUG_LOG file irrespective of what you set the error_log directive to in the /usr/local/etc/php/conf.d/error-logging.ini file [1]. This assuming you have WP_DEBUG enabled. If the WP_DEBUG is disabled then only the error_log directive will make a difference. If you want to log to a location other than WP_DEBUG_LOG specify the location explicitly in the error_log function using message type 3. Logging to /dev/stderr or /proc/self/fd/2 or /proc/1/fd/2 will not make the messages appear in docker logs [2]

My goal in this exercise was to be able to see my application logs when I run the docker logs command. As I learned this is not possible without some advanced hacks which I didn’t get into. The first lesson I learned is that when docker logs is called it only outputs the logs of the PID 1 process running inside the container. Further these logs are stored in the special file /proc/1/fd/2 which is a pipe

bash-5.0# ls -al /proc/1/fd/2
l-wx------    1 root     root            64 Mar 24 17:15 /proc/1/fd/2 -> pipe:[20292]

You can try echoing something into /proc/1/fd/2 and it will immediately appear in docker logs. Some posts say to log to /proc/self/fd/2 to make log messages appear in docker logs but it does not work. And logging to /proc/1/fd/2 from your application also does not work because of permissions related limitations.

Re: the location where messages are logged by default, I found two places where this location is defined in form of error_log directive. These two locations are:

/usr/local/etc/php/conf.d/error-logging.ini
/usr/local/etc/php-fpm.d/docker.conf

Which of these two is relevant and matters ultimately? The directive in

/usr/local/etc/php-fpm.d/docker.conf

is controlling where the PHP-FPM process and the www child processes it forks will output their messages. This directive is explained in php-fpm’s configuration file. By default the logs of child processes are discarded unless the catch_workers_output option is set to yes. One can see the www child processes in the output below:

bash-5.0# ps aux | grep php
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   72 www-data  0:00 php-fpm: pool www
   73 www-data  0:00 php-fpm: pool www

It is the child processes which run our application code inside the container. You can see the child process runs as www-data i.e., has privileges associated with www-data user. PHP-FPM exposes a log_level directive that can be tweaked to control the verbosity of PHP-FPM logs. By default it is set to notice. Try setting it to debug in /usr/local/etc/php-fpm.conf (or the /usr/local/etc/php-fpm.d/docker.conf file) and you will see the difference.

; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
;log_level = notice
;log_level = debug

Coming back, the directive that controls where application logs are output (by application logs I mean log messages that are output as result of calling PHP’s error_log function) is defined in

bash-5.0# cat /usr/local/etc/php/conf.d/error-logging.ini
error_reporting = E_ERROR | E_WARNING | E_PARSE | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING | E_RECOVERABLE_ERROR
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /dev/stderr
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

The /dev/stderr is symlink to /proc/self/fd/2 which is a link to /dev/pts/0 which exists only while a terminal is attached to a container

bash-5.0# ls -al /dev/stderr
lrwxrwxrwx    1 root     root            15 Mar 24 17:15 /dev/stderr -> /proc/self/fd/2
bash-5.0# ls -al /proc/self/fd/2
lrwx------    1 root     root            64 Mar 24 18:23 /proc/self/fd/2 -> /dev/pts/0

When the container is detached from any terminal you will observe

WITSC02X6385JGH:~ sjain68$ docker exec wordpress ls -al /proc/self/fd/2
l-wx------    1 root     root            64 Mar 24 18:24 /proc/self/fd/2 -> pipe:[23169]

I think the pipe in above is only temporary. Anyway logging to /dev/stderr does not cause messages to appear in docker logs. And I have tried logging to /proc/1/fd/2 directly and it gives this error:

[23-Mar-2021 20:26:06 UTC] PHP Warning:  error_log(/proc/1/fd/2): failed to open stream: Permission denied in /var/www/html/wp-content/logging.php on line 11

The funny thing is that on another container I do see application logs in docker logs. On this container I observe:

$ docker exec -it wordpress ls -al /proc/self/fd/2
lrwx------    1 root     root            64 Mar 24 18:27 /proc/self/fd/2 -> /dev/pts/1

The confusion does not end here. I changed the log location in /usr/local/etc/php/conf.d/error-logging.ini and it did not make any difference. It turns out that when WP_DEBUG is enabled, WordPress overrides whatever log location you may have set in /usr/local/etc/php/conf.d/error-logging.ini with the log location given by WP_DEBUG_LOG. The code that does this can be found here.

Laws that You did not Learn in School

01. *LORENZ’S LAW OF MECHANICAL REPAIR*
Once  your hands become coated with grease, your nose will begin to itch.

02. *ANTHONY’S LAW OF THE WORKSHOP*
Any tool, when dropped, will roll to the least accessible corner.

03. *KOVAC’S CONUNDRUM*
When u dial a wrong number, u never get an engaged tone.

04. *CANNON’S KARMIC LAW*
If u tell the boss u were late for work because u had a flat tyre, the next morning u will have a flat tyre.

05 *O’BRIEN’S VARIATION LAW*
If u change queues, the one u have left will start to move faster than the one u are in now.

06. *BELL’S THEOREM*
When the body is immersed in water, the telephone rings.

07. *RUBY’S PRINCIPLE OF CLOSE ENCOUNTERS*
The probability of meeting someone u know increases when u are with someone u don’t want to be seen with.

08. *WILLOUGHBY’S LAW*
When u try to prove to someone that a machine won’t work, it will.

09. *ZADRA’S LAW OF BIOMECHANICS*
The severity of the itch is inversely proportional to the reach.

10. *BREDA’S RULE*
At any event, the people whose seats are farthest from the aisle arrive last.

11. *OWEN’S LAW*
As soon as u sit down to a cup of hot coffee, your boss will ask u to do something which will last until the coffee is cold.

12. *SID’S LAW*
When you need something you will never find it in your home.

13 *NEERA’S LAW*
After you throw something you will immediately need it the next day.

Career Advice

The pros and cons of being a software engineer at a BIG tech company

If you end up working in a non-FAANG industry, you’ll see fewer developers and less support from non-technical staff, but you’ll have plenty of opportunity to add massive value. 

Another distinct difference for software engineers is that you’re seen as a liability, whereas FAANG companies would view you as an asset. At a FAANG company, you’re valuable because you contribute to the bottom line. At a company in a tech industry, this isn’t always the case. The company will view you like every other business function. You’re an expense that has to prove itself every year, sometimes every quarter. 

Because of this, a company outside the software industry is likely to pay you less. The company will want to pay the direct contributors first. This group may be project managers, auditors, or even account executives. But if your software isn’t a key driver for revenue, don’t expect to earn a hefty salary. 

Based on my experience, outside of software-driven industries, you may be more likely to work with temporary employees. Companies often want to integrate software into their business but are not be willing to pay for a full-time developer. They will then hire temporary workers that work for six to twelve months at a time. There are many issues that may arise with temporary workers. Contractors may not understand your development infrastructure. You might spend unnecessary time making sure both of you are on the same page. When they leave, you may be the one who has to take extra time to understand the code they left behind. Any knowledge they have often leaves the company when they do.

How to debug WordPress PHP code running inside a Docker container from VS Code

This article describes the steps you need to do to debug WordPress PHP code that is running inside a Docker container. The instructions here are tested to work with a Docker container based on wordpress:php7.4-fpm-alpine image. For other images YMMV when following these instructions (esp. the part where we install Xdebug)

The first step is to install Xdebug  which is PHP’s debugger. Do this by running following from inside the Docker container ref  (Do not install Xdebug using apk add or you will run into issues ):

apk --no-cache add pcre-dev ${PHPIZE_DEPS} \ 
  && pecl install xdebug \
  && docker-php-ext-enable xdebug \
  && apk del pcre-dev ${PHPIZE_DEPS}

This will do following things:

• build and install Xdebug (v3.0.2 at time of this writing) under /usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
• create a /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini file with just following line in it:

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so

You can now check if Xdebug is installed successfully by running:

bash-5.0# php -v
PHP 7.4.4 (cli) (built: Mar 24 2020 01:34:16) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v3.0.2, Copyright (c) 2002-2021, by Derick Rethans
    with Zend OPcache v7.4.4, Copyright (c), by Zend Technologies

If you want to see all the ini files that PHP loads, you can do that by running:

# php --ini

Now to enable remote debugging add following lines to docker-php-ext-xdebug.ini:

xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port = 9000
xdebug.remote_handler=dbgp
xdebug.client_host=host.docker.internal
xdebug.idekey=VSCODE
xdebug.log=/usr/local/etc/php/xdebug.log

If the log file does not exist one will be created at time of debugging. But it gets created with root as its owner and is inaccessible to the www-data user which is the user php-fpm runs as. So you might as well create the file and chown the owner to www-data.

Refer this  page for an explanation of the settings.

Install PHP debug extension for VS Code. After installing the extension, create or open existing launch.json and add following section to it:

{
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "log": true,
            "externalConsole": false,
            "pathMappings": {
                "/var/www/html": "${workspaceRoot}/www-html",
            },
            "ignore": [
                "**/vendor/**/*.php"
            ]
        }

The pathMappings is used to map code inside the Docker container to code stored locally. Correct it as appropriate in your case. The port should match the port declared in xdebug.client_port.

Now run VS Code in debug mode with above configuration. The blue ribbon should turn orange and you will be able to set breakpoints.

Next, we need to restart the php-fpm process for xdebug settings in docker-php-ext-xdebug.ini to take effect. I do this by just restarting the container. An alternate way – one that I haven’t tried – is to run this  from inside the container:

# kill -USR2 1

Now you can make a request and the VS Code debugger should break!

You might be wondering two things:

• we have php-fpm running on port 9000 in our Docker container. Then how come we can use same port in xdebug.client_port?
• we did not have to publish the port. How come VS Code is able to connect to Xdebug?

The answer is that it works because Xdebug is the client and it is VS Code that is the server in this setup!

If you don’t have VS Code running you will see following errors in Docker log because Xdebug is not able to connect to VS Code:

NOTICE: PHP message: Xdebug: [Step Debug] Could not connect to debugging client. Tried: host.docker.internal:9000 (through xdebug.client_host/xdebug.client_port) 😦

Comment out the xdebug settings (i.e., turn xdebug off) when VS Code is not running to avoid the errors.

Exchange of text messages between Husband and Wife

Exchange of text messages:

Husband: You are negative

Wife: and you are stubborn, arrogant, a low life, care about no one but yourself and your friends, all you are interested in is your own self, all your life not fulfilled even one of your promises. It is only I who is putting up with such a miser and insensitive man. You good for nothing, fat, ugly man. Even your hair transplant failed.

Husband: I was just informing you that your Covid test is negative.

Wife: oh………sorry!

Notes on Programming Hyperledger Fabric

I just finished writing a book:
https://www.amazon.com/dp/0578802228

In this post I am making some notes and fun facts about the book for remembrance.

Original TOC

Final TOC

Blockchain Primer Introducing Hyperledger Fabric A proof of concept app Setting up your infrastructure Securing communications with OpenSSL Establishing the user registry with LDAP Generating certificates with Fabric CA Membership services and policies Transaction ordering The Peers Channels Implementing business logic using Chaincode Fabric Node.js SDK Advanced Topics Appendix A: Installation and setup

Blockchain Primer A Closer Look at Fabric Writing Your First Smart Contract Generating Identities Required to Bootstrap a Network Provisioning a Three Org Test or Development Network Debugging Fabric Provisioning Channel and Installing Chaincode Performing Transactions on the Network Updating Channel Configuration Dockerizing the Network Securing Communications with TLS Handling Data Privacy Running Fabric CA Server Using Fabric CA Client to obtain X.509 Certificates Authenticating Users using LDAP Bonus Chapter: The Bitcoin Appendix A: Installing Software and Prerequisites Appendix B: Summary of Commands

And here is a word cloud – list of most commonly occurring words in the book curated to remove common words like like, when, which, user, using, then, what etc.

$ python counter.py full.adoc
[('Fabric', 447), ('peer', 446), ('chaincode', 330), ('certificate', 314), ('Docker', 290), ('orderer', 287), ('client', 285), ('block', 250), ('server', 237), ('container', 224)]

The full manuscript itself is about 1MB in size containing about 150,000 words

$ ls -al full.adoc
-rw-r--r--  1 sjain68  staff  1033787 Dec 17 10:26 full.adoc
$ wc -w full.adoc
  151713 full.adoc

VS Code + AsciiDoc

Today I learned that VS Code has a pretty good extension for AsciiDoc:

https://marketplace.visualstudio.com/items?itemName=asciidoctor.asciidoctor-vscode

It can even export to PDF using wkhtmltopdf. There is also the option to have it use the Ruby based asciidoctor-pdf to do the conversion.

How to Use

The extension activates automatically when opening an AsciiDoc file (.adoc, .ad, .asc, .asciidoc).

Preview

To show the preview you can use the same commands as the Markdown extension:

• Toggle Preview – ctrl+shift+v (Mac: cmd+shift+v)
• Open Preview to the Side – ctrl+k v (Mac: cmd+k v)

The preview refreshes automatically, but it can also be forced with the AsciiDoc: Refresh Preview command.

The preview supports setting attributes through the asciidoc.preview.attributes option.

By default the preview style follows the VSCode theme (workbench.colorTheme). To use Asciidoctor’s style set option asciidoc.preview.useEditorStyle to false. It is also possible to set your own preview stylesheet with the asciidoc.preview.style option.

(See more details under Options)

Export as PDF

The extension provides a quick command to export your AsciiDoc file as PDF.

• Open the command palette – ctrl+shift+p or F1 (Mac: cmd+shift+p)
• Select AsciiDoc: Export document as PDF
• Choose the folder and filename for the generated PDF

By default a separate binary is downloaded and used to render the document in PDF format. To use Asciidoctor PDF set option asciidoc.use_asciidoctorpdf to true.
(See more details under Options)

To change the settings first open the extensions tab. then select Asciidoc extension. click on gear icon as shown below

also see https://stackoverflow.com/questions/50477523/how-to-convert-asciidoc-to-pdf/50709725