Showing posts with label configuration. Show all posts
Showing posts with label configuration. Show all posts

How to solve "detected dubious ownership in repository" when "directory = *" does not seem to have any effect

The issue

This week me and my team started to get a weird git message

fatal: detected dubious ownership in repository [directory]

that basically did not allow us to pull nor push changes.

 

The simple solution that did not work

Most of the issues seemed Windows related and I was on Kubuntu, but I assumed that the operating system would not be a point of interest, which, in the end, proved to be correct.

All solutions pointed to the execution of a simple command

git config --global --add safe.directory [directory]

which would, simply, add the [directory] to the ~/.gitconfig file and that would mark the [directory] as being trusted and thus solving the issue. A more simple approach would be using * as the [directory], basically saying any directory.

And that was the road that I took. But with no success. I even tried --system instead of --global which would set that configuration at the system level (in /etc directory) instead of the making it only available to the user.

I ended up with a ~/.gitconfig file like this:

[user]
       email = [email protected]
       name = M6
[safe]
       directory = *

But nothing seemed to work.


The suspicious directory

Early on, I did notice something weird. The [directory] presented in the solutions referred to local paths, but the [directory] I was getting was the repository server path.

If it was a local issue, the [directory] would be something like /home/m6/work/repo_project but I was getting /var/git/repo_project, which only exists on the repository server.

While doing the investigation, I did came across with a project that was working fine! This raised my doubts about that local ~/.gitconfig file being if any use since the that particular repository worked fine with, or without that file being present on the system.


The solution

I logged on the repository server and checked that my user had a ~/.gitconfig file present with the directory parameter pointing precisely to the path of the only project that was working fine.

I changed the value *, which means any path, gave it a try and suddenly the problem was solved for me.

I checked with my team and since the server is solely dedicated to be a git repository server, most of the people do not have a real home in the system since they do not have the need to work on the server.

The solution for the team users that do not have a home was to create a dummy /home/gitdummy directory, create a .gitconfig file holding

[safe]
       directory = *

and finally change the users home in the /etc/passwd file pointing it to /home/gitdummy.


Summary

In short, if you run into this issue and the straight forward solution does not seem to work for you as it did not for me, check where the path is located, enter on that system and add

[safe]
       directory = *

to the ~/.gitconfig file of your user.

If you run into a transversal issue affecting all users of that system, just apply that solution to all of them.

If the users do not have a home on that system, create a dummy home and point the users home to it.


./M6

How to setup VSCode launch.json for Xdebug version 2

I had to make some maintenance on a web application using Yii 1.1.4 framework running on PHP 7 and for that, I set up an Ububtu 18.04 LTS Desktop on a virtual machine. 

After the usual bunch of "apt-get install" commands and a few configurations, I got the new development environment up and running having Visual Studio Code as my IDE.

But, almost as soon as I got it running, I got the need to step debug it. For that, I went to Xdebug, I installed it via "apt-get" and configured it, but it was not working as expected.
I check the configuration parameters and give it another try. No go. Xdebug was installed, PHP was recognizing it on both cli and web, but it was still not working.
After a few seconds, I spotted the issue: it was a Xdebug version 2!

A lot has changed between version 2 and 3 of Xdebug.

The thing was that I wanted to keep version 2, and for that I had to configure "launch.json" file and Xdebug in the appropriate way.

On PHP configuration file:

zend_extension=xdebug.so
xdebug.idekey=XDEBUG_VC
xdebug.remote_port=9003
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
 
And on "launch.json":

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
       
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 0,
            "runtimeArgs": [
                "-dxdebug.remote_autostart=yes"
            ],
            "env": {
                "XDEBUG_MODE": "debug,develop",
                "XDEBUG_CONFIG": "client_port=${port}"
            }
        },
        {
            "name": "Launch Built-in web server",
            "type": "php",
            "request": "launch",
            "runtimeArgs": [
                "-dxdebug.mode=debug",
                "-dxdebug.remote_autostart=yes",
                "-S",
                "localhost:0"
            ],
            "program": "",
            "cwd": "${workspaceRoot}",
            "port": 9003,
            "serverReadyAction": {
                "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started",
                "uriFormat": "http://localhost:%s",
                "action": "openExternally"
            }
        }
    ]
}

The default port is 9000, but I'm used to have Xdebug on 9003, so I reconfigured it. The remaining parameters are, basically, the version 2 way of activation the debugger on a request.

./M6

EHCP VirtualHost Django Applications Configuration

While deploying a Django application on an Easy Hosting Control Panel environment following the guide about how to configure virtual hosts totally failed because the configuration was not written in the correspondent Apache file.

So, I had to hack the system in order to make it work. It's as simple as edit the
/var/www/new/ehcp/apachehcp.conf
file where all virtual hosts are defined.

./M6

Setting up Drupal

Here's a quick guide for Drupal installation and configuration with a minimum of useful base components.

To exemplify, I'll use Lampp, but for Xampp it won't be much different.

Before you start, go to your php.ini file and increase the memory_limit parameter to, at least, 16 megabytes and restart your webserver in order to apply the changes. This amount of memory is usually enough, but when in trouble, use a bigger value, like 24 or 32.
The php.ini file location depends on your system. In Lampp, for instance, it is in /opt/lampp/etc/php.ini, in Windows it is somewhere under the apache directory.

First, get the latest version of Drupal, currently 6.10.

Uncompress the .tar.gz using tar -zxvf drupal-6.10.tar.gz and copy its contents into the web server web site location.
From now on, the Drupal install location is referred only as {install_location} and the web site will be referred as {mywebsite}.
A Lampp/Xampp example of the {install_location} would be {lampp}/htdocs/{mywebsite}.

If you want Drupal in diferent languages, get the necessary translations for your Drupal version. Uncompress the files and copy the contents into the Drupal install location. Using the previous example, the file contents go into {install_location}.

Copy the {install_location}/sites/default/default.settings.php file to {install_location}/sites/default/settings.php, i. e., make a copy of the file in the same directory and rename it to settings.php.
In the same location, create a new directory named files and make it writable.
Under Linux, both settings.php file and the {install_location}/sites/default/files directory must be writable, therefor perform a chmod +w to both.

Access your database engine, currently MySQL and PostgreSQL and create the database and correspondent user and password for the created database.
This has to be done because Drupal installation does not perform the database creation.

Assuming there's a web server already running on localhost, install Drupal by pointing your browser address to http://localhost/{mywebsite} and just follow the installation wizard. In the database configuration remember to refer the previously created database and user.

After the creation of the database fill in the site configuration information and save the changes.

The installation should finish without trouble. At the end, there is a link pointing to your new site. Just click on it and you will be redirected to the web site using administration credentials.

But that is raw Drupal installation. Usually one wants a nice template a WYSIWYG editor, an integrated content media management, so that one can upload videos, pictures and other documents.
Some of these modules actually should already be part of the Drupal default modules and should already be configured for default usage.

The add-on modules and themes go into a special directory, they are not mixed up with the default modules nor themes, and they have a standard installation procedure. The themes go into {install_location}/sites/all/themes/ and the modules go into {install_location}/sites/all/modules/. These directories do not exist on a new Drupal installation. When using Linux, do not forget to give the appropriate access permissions to these directories and its contents.
When in doubt, read to the module or template documentation.

Start with the template, get a template for your Drupal version and download it. Uncompress it and copy its contents to {install_location}/sites/all/themes/{newtheme}. It is possible to and install as many themes as necessary.
To select a new theme, go to the menu option Home › Administer › Site building, mark the desired template as the default nd press the Save configuration button.

Installing a WYSIWYG HTML editor requires two modules, the base WYSIWYG API module and an HTML editor, like FCK Editor. Uncompress the WYSIWYG API module file and copy its contents into {install_location}/sites/all/modules/wysiwyg. As a curiosity, the {install_location}/sites/all/modules/wysiwyg/editors directory have all the supported HTML editors, there is an .inc file for each supported editor.
To install the FCK Editor, uncompress the file and copy its contents into the editor directory inside the WYSIWYG API install directory, {install_location}/sites/all/modules/wysiwyg/fckeditor.

To activate the HTML editor module, go to the menu option Home › Administer › Site building, enable the Wysiwyg user interface module and press the Save configuration.

To configure the HTML editor, go to the menu option Administer > Site configuration > Input Formats, press Add input format. Name it Default HTML Editor, select both roles, and disable HTML filter, Line break converter and URL filter. Press Save configuration button, go back to Administer > Site configuration > Input Formats and select the Default HTML Editor as the default HTML editor.

Now setup editor profiles in Administer > Site configuration > Wysiwyg menu option.
Select FKCEditor (version) for all Input formats and press Save.

There are many available modules for many extra functionalities. A recomended administration module is the Administration Menu, witch provides easy and fast access to administration items.

For instance, if you're looking for an e-commerce solution, check out Ubercart. To set it up, check the How to make an online store look great with your new theme from TopNotchThemes and the Ubercart User's Guide for a quick start.

./M6