Renaming a git branch (from server to local)

Recently got this useful info from GitHub on updating a git branch locally after renaming it on the server.

Assuming the branch’s old name was ‘main‘ and it is renamed to ‘master‘, and its local clone exists, execute the following on local terminal:

git branch -m main master
git fetch origin
git branch -u origin/master master
git remote set-head origin -a

That should successfully complete the renaming of the branch (at the local end).

XDebug 3.x configuration for PHP/Apache on a Docker container & debugging via vscode

XDebug configuration

‘xdebug 3.x‘ has some different configuration parameters than the older 2.x version. Here is the quick set of parameters required for xdebug to work with Apache running on a Docker container:

xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.mode=debug
xdebug.discover_client_host=1

Note that client_host value ‘host.docker.internal‘ may not work on linux.

Another important part here is the value for 'xdebug.discover_client_host‘ . It must be set ON for xdebug to work with Apache. It does work with CLI with this option OFF also, but didn’t seem to work with Apache without this option set to 1.

Caveat: xdebug.mode as ‘debug‘ , the improved/formatted output of var_dump() that xdebug gives, gets turned off. In order to have formatted var_dump() output, xdebug.mode needs be set to ‘develop‘. In ‘develop’ mode, vscode-debugger does not work. This is due to the changes in version 3 of xdebug.

UPDATE: Found out that xdebug.mode can have comma-separated multiple values as:

xdebug.mode=develop,debug

For the PHP-Apache Docker image I was using (php:7.4-apache), the php.ini was not created by default. So I copied the development-sample /usr/local/etc/php/php.ini-development

The xdebug config is set in a separate file: /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

vscode config (launch.json)

In order to work with the vscode extension PHP Debug (by Felix Becker), a vscode configuration file (launch.json) needs to be created. An important parameter here is ‘pathMappings‘. Here’s a working example of launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9003,
            "pathMappings": {
                "/var/www/html/projectDir": "${workspaceFolder}"
            }
        }
    ]
}

The first part in “pathMappings” value corresponds to the document-root in Apache on Docker. The latter is the corresponding local path on the host system. ${workspaceFolder} is a convenient variable translating to the location of the project containing the ‘.vscode‘ directory.

The other customisation is the “port” value (‘9003‘ for xdebug 3.x), matching with the xdebug.client_port value in PHP.

A useful PHP function to get the stats for xdebug is: xdebug_info()

This set up should make ‘PHP Debug’ extension to work in vscode by assigning breakpoints in the code. In case the debugger does not stop at the breakpoints, xdebug can be tested by setting the following parameter in launch.json:

"stopOnEntry": true

This makes the debugger to stop at the entry point of the PHP script.

Installing MongoDB on cPanel / WHM / CentOS along with the PHP extension

Attempts to install MongoDB on a cPanel based CentOS VPS

While trying to install MongoDB on a cPanel based CentOS server, I found the system configurations were customised by cPanel. And because of which a lot of commands were not available in bash. Also the installation of some packages was disabled in the /etc/yum.conf (e.g. php* in the ‘exclude’ list blocked the installation of php-devel package, etc.). This is a documentation of the key steps to install MongoDB on such a system.

I referred the official doc on mongodb.com to install mongodb on CentOS. So at the time of writing this, the version provided in the doc to install was 4.4.

Please note that I did the installation as ‘root’ user.

Ref. https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/

1.Create a repo file in /etc/yum.repos.d called mongodb-org-4.4.repo with this content:

[mongodb-org-4.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc

2. Install the MongoDB packages

yum install -y mongodb-org

3. Configure MongoDB to auto-start on system startup / reboot

chkconfig mongod on

Output:

Note: Forwarding request to 'systemctl enable mongod.service'.

4. Start MongoDB

service mongod start

Output:

Redirecting to /bin/systemctl start mongod.service

5. Install MongoDB PHP Extension

Note that cPanel has the tools like pecl, phpize, etc. in the following location. Change the version in “ea-php*” as per your PHP version. There could be multiple versions of PHP installed, so choose the version you are using for the project.

/opt/cpanel/ea-php74/root/usr/bin/

So to run phpize followed by ./configure while compiling a package yourself, use something like:

/opt/cpanel/ea-php74/root/usr/bin/phpize && ./configure --with-php-config=/opt/cpanel/ea-php74/root/usr/bin/php-config

PHP extension installation with the pecl tool:

/opt/cpanel/ea-php74/root/usr/bin/pecl install mongodb

Ref. https://www.php.net/manual/en/mongodb.installation.pecl.php

Note that some references ask to install ‘mongo‘ as the extension, but it is the old extension, and with PHP 7 you need to install ‘mongodb‘ as the extension.

A successful installation should end with something like:

Build process completed successfully
Installing '/opt/cpanel/ea-php74/root/usr/lib64/php/modules/mongodb.so'
install ok: channel://pecl.php.net/mongodb-1.9.0
Extension mongodb enabled in php.ini

Info: Location of php.ini on cPanel:

/opt/cpanel/ea-*/root/etc/php.ini

6. Restart Apache

service httpd restart

Deploying a template in Visual Studio

I had to use MS Visual Studio to work with Graphisoft’s Archicad API. The API kit installs a template in Visual Studio, though the references to the libraries and header files in the template have a relative path specially for the example projects that come with the kit. That required editing the path to the referenced files in the template in order to use it for projects stored in locations other than the Examples directory of the API kit.

The templates in Visual Studio are stored in the form of a ZIP file. Though the decompressed template can be customised by editing, duplicating the template with customisations is not as simple as unzipping the template, edit the files and re-zip as a new template to be available in Visual Studio. From what I gathered, Visual Studio 2017 onwards, the templates are not simply scanned for in their directories. They are instead required to ‘provide some “manifest” file storing the template’s location’ (Ref).

This is a compilation of the steps to generate a usable template in Visual Studio 2017 (community) using broadly gathered info, not describing the mechanism or the structure of the template.

An existing project-template can be found in %userprofile%/Documents/Visual Studio 2017/Templates/ProjectTemplates Duplicate the ZIP file of the template, extract and customise it. Re-compress it into a ZIP file.

(It seems some tags need to be defined in the <Template Data> section in the .vstemplate file, for compatibility with v2019. Ref.)

In order to deploy this customised template, a VSIX project template is needed. The VSIX project template becomes available in the New Project dialog box (search vsix) after installing the Visual Studio SDK. To install Visual Studio SDK, run the Visual Studio installer and install ‘Visual Studio extension development’ workload. Ref.

After the VSIX project template is available in the New Project dialog in Visual Studio:

  • Create a new VSIX project using the Visual C# VSIX template.
  • Right-click on the VSIX project in the Solution Explorer and select ‘Set as Startup Project’.
  • Browse the Solution Explorer for a source.extension.vsixmanifest file. Double-click to open it, and a form opens up.
  • In the ‘Assets’ section, select New. In the ‘Add New Asset’ dialog box, select Type as Microsoft.VisualStudio.ProjectTemplate and Source as ‘File on filesystem’. Browse and select the ZIP file of the template. The template ZIP file should now be listed in the Solution Explorer under ProjectTemplates.
  • Build the project for release version. Browse to the bin > Release directory of the VSIX project, and run the .vsix file that was generated to install the template.
  • The template should now be available in the New Project dialog box after restarting Visual Studio. Search for the template by the <Name> specified in <TemplateData> of the .vstemplate file.

Hope this helps someone. Share your thoughts / suggestions please. Thanks.

Change windows10 Alt+Tab navigation back to classic icons instead of thumbnails

In the registry editor, reach HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer.

Add a new DWORD key: AltTabSettings and change its value to 1.

Restart Explorer (Launch the Task Manager, find ‘Windows Explorer’ in the group ‘Windows processes’, right-click it and ‘restart’)

Now Alt+Tab should display only the application icons.

To revert back to the thumbnails, change the registry-key (AltTabSettings) value to 0.

Removing a directory from the git repository after adding it to .gitignore

If a directory was added to .gitignore before pushing to the repository, it does not get pushed. But if the directory was already pushed, and later added to .gitignore, then to remove it from the repository:

git rm -r --cached dirToIgnore
git commit -m 'Removing the gitignored dir'
git push

The directory dirToIgnore should now be removed from the git repository.

Fixing Apache localhost/~username resolve on macOS Mojave

Edit /etc/apache2/httpd.conf

sudo vi /etc/apache2/httpd.conf

Uncomment the following lines:

#LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
#Include /private/etc/apache2/extra/httpd-vhosts.conf
#LoadModule userdir_module libexec/apache2/mod_userdir.so
#Include /private/etc/apache2/extra/httpd-userdir.conf

Uncomment the following in /private/etc/apache2/extra/httpd-userdir.conf :

#Include /private/etc/apache2/users/*.conf

Create the file /private/etc/apache2/users/yourUserName.conf if it doesn’t exist:

sudo vi /private/etc/apache2/users/yourUserName.conf

Add the following in this file:

<Directory "/Users/yourUserName/Sites/">
  Options Indexes MultiViews
  AllowOverride None
  Require all granted
</Directory>

For running PHP, uncomment the following line in /etc/apache2/httpd.conf . The version of PHP in the module name may vary as per the currently installed version (7 in this case):

#LoadModule php7_module libexec/apache2/libphp7.so

Restart Apache server:

sudo apachectl restart

The local webserver should now be available at http://localhost/~yourUserName/ , referring to the location ~/yourUserName/Sites/

using git to deploy on server

Install git on the remote server (if it is not already).

On Ubuntu:

sudo apt-get update
sudo apt-get install git

Create an SSH key pair (locally):

ssh-keygen -C "email@domain.com"

Accept the default file to save the key. If a passphrase is entered, it would have to be entered every time during ‘git push‘. The following two files would be created in ~/.ssh/

id_rsa.pub (public key)
id_rsa (identification)

Create an authorized_keys file (if it is not present) on the remote server in ~/.ssh/ for the SSH daemon to accept the key:

touch ~/.ssh/authorized_keys

Copy the local SSH ID/key to the remote server’s authorized_keys in ~/.ssh/ as:

ssh-copy-id user@remoteServerIP

It would prompt for the passphrase if it was entered while generating the key (using ssh-keygen).

Create a local git repository, in a project directory (say ~/project01) that needs to be uploaded to the server. Then create a file in it to test the git transfer later:

cd ~/project01
git init
echo 'testing deployment via git' > example.txt 

On the remote server, initialise a bare repository in a directory (say ~/project01.git):

mkdir ~/project01.git && cd ~/project01.git
git init --bare

Set up a post-receive hook for ~/project01.git on the remote server, to ‘checkout’ the git files into a remote project directory (say ~/project01, as the local):

mkdir ~/project01
nano ~/project01.git/hooks/post-receive

Enter the following script code in this post-receive file:

#!/bin/sh
export GIT_WORK_TREE=/home/user/project01
git checkout -f master

Make post-receive executable:

chmod +x ~/project01.git/hooks/post-receive

Set up remote origin to the server (bare) repository, at the local end:

git remote add origin user@remoteServerIP:project01.git

Stage the content of the local repository and commit it:

cd ~/project01
git add example.txt
git commit -m "New sample file to test git transfer"

Push the sample file to the server, setting the remote as upstream:

git push --set-upstream origin master

The file should be available on the remote server at ~/project01 (created earlier).

Note: It is recommended against using git as a deployment tool, for reasons as it does not track permissions. Read here.

komorebi

komorebi – sunlight filtering through the trees

木漏れ日

木 – tree

漏れ – leakage

日 – sun

byobu

http://byobu.co/

A text-based window manager for linux and terminal multiplexer; displays system info in the CLI, such as battery, hdd, thermal stats.