Support

UNiTE, Remote CLI, eXtract Wizard

#35058 – .htaccess ownership after restoration seems to interfere with

Posted in ‘UNiTE, Remote CLI, eXtract Wizard’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 14 April 2021 04:02 CDT
pjdevries

As the title of this issue describes, the .htaccess ownership after a restoration seems to interfere with <replacehtaccess>.

My environment is as follows:

  • Windows 10 Pro
  • WSL2
  • Docker Desktop 3.3.0 (build: 62916) with Docker Engine v20.10.5
  • Ubuntu 20.04
  • httpd container 74-apache:latest (Debian 10 (buster))

Creation and restoration of the backup works fine. However, the .htaccess file is not replaced with the Joomla! default, eventhough <replacehtaccess> is set to '1'. Allthough the ownership of all restored files is set to 'www-data', the .htaccess file is owned by 'root'. I guess that's the reason why it is not replaced.

Is there a way to solve this?

Custom Fields

Which tool do you want support for? UNiTE
Tool version (in x.y.z format) 4.1.2 (2020-11-17)
 
Wednesday, 14 April 2021 08:32 CDT
nicholas

We do NOT control the ownership of your files. We can't, at all. Our PHP software runs, well, inside PHP itself. PHP is constrained to run under a specific user based on what the server administrator (that's you) has configured in the server (that's your server / container).

The obvious reply to your issue is to figure out your container setup so everything is a using the same user. This is way beyond the scope of our support.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 14 April 2021 09:07 CDT
pjdevries

Thanx for the swift reply. I will not try to debate whose responsibility it is to set the proper ownership of a file that is created by UNiTE. Debating is not my strong suite (understatement) :)

I made some modifications to the shell script that starts UNiTE, so UNiTE is now executed as the apache user . It now looks like this:

#!/bin/bash

php=/usr/local/bin/php
apache=$(ps aux | egrep '([a|A]pache|[h|H]ttpd)' | awk '{ print $1}' | uniq | tail -1)

su -c "$php unite.phar unite.xml" $apache

After running UNiTE, the ownership of the .htaccess file is now correctly set to 'www-data'. However, its contents is rather peculiar:

## Akeeba UNiTE - Stealth .htaccess file
Order Deny,Allow
Deny From All
Allow From 172.20.0.2 127.0.0.1 localhost

Doesn't look much like the Joomla! default.

Any ideas or is this still way beyond the scope of your support?

 
Thursday, 15 April 2021 04:15 CDT
nicholas
 I will not try to debate whose responsibility it is to set the proper ownership of a file that is created by UNiTE. 

I WILL debate this and I do not appreciate your sarcasm. Being sarcastic against the person trying to help you only works against you. It won't change the fact that this is how YOUR server works, according to how YOU set it up.

Once again. There is NO PHP function that can change the ownership of a file. PHP can only change the permissions of a file. The ownership of the file is the same user and group the PHP process runs under. This is how PHP works. If you don't understand that try to educate yourself by listening to people who know these things better than you and / or reading up on the subject. A good place to start is the Security Information chapter of the Akeeba Backup documentation which I wrote to educate people like you.

After running UNiTE, the ownership of the .htaccess file is now correctly set to 'www-data'. However, its contents is rather peculiar:

When UNiTE starts extracting your site it writes a "stealth .htaccess" like Kickstart's eponymous option. This makes your site inaccessible to other people while the restoration is in progress. The .htaccess file is extracted as htaccess.bak. When UNiTE finishes the restoration successfully it will remove its .htaccess file and rename htaccess.bak to .htaccess just like Kickstart does.

So, one of the following is going on:

  • UNiTE did not finish restoring the site. It tells you whether it's successful or not. Check its output.
  • You had a htaccess.bak file in your backup with these contents, backed up AFTER .htaccess itself. First the .htaccess is extracted as htaccess.bak. Then the "wrong" htaccess.bak is extracted, overwriting the previous file. At the end of the restoration the "wrong" file is renamed to .htaccess.
  • These were the contents of the .htaccess file of your site. This could happen if you had started a restoration with Kickstart but never ran the Clean Up step.

For your information, I am using Akeeba UNiTE on a daily basis. I restore the latest backup of our site on my dev machine. I also use it 2-3 times every week to transfer dev sites between two different dev machines. Needless to say, there are .htaccess files in all of these cases. I know how to set up my own servers and have done that in a way that doesn't cause any of the problems you have. You know how? I have set up a specific user which owns all of the files, it's the same one Apache and PHP-FPM are using and the same one that runs Akeeba UNiTE.

Whenever I use Docker I use a variation of https://github.com/nikosdion/efficacious-whale which has the files hosted outside the container. However, Docker is too slow for practical development so I'd rather use a virtual machine or my dev machine directly.

So, yes, I am pretty damn sure that your problem is self-inflicted and comes down to server configuration. I understand exactly how file ownership / permissions work and the same for Linux, macOS, Windows, Apache, PHP and Docker. What do you think? I write a backup application for 15 years that just happens to work across a plethora of server environments? There's a lot of hard work and VERY specific domain knowledge about servers that goes into making and maintaining it. So, maybe, you'd like to just fix your setup instead of being a sarcastic jerk? Thanks.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 15 April 2021 04:37 CDT
pjdevries

'So, maybe, you'd like to just fix your setup instead of being a sarcastic jerk?'

I'm using and paying for your software for about 11 years of the 15 you are developing it. I should have known I could expect this kind of response, no matter how informative as well, because you always do this. You always insult people who seem less educated than you, treating them in a very offensive and insulting manner. There is absolutely no reason to always behave like such a bully and calling people names.

 
Thursday, 15 April 2021 06:45 CDT
nicholas

You came here with a file ownership issue. I explained very calmly that our PHP-based software runs inside PHP itself which determines the file ownership. Remember that this is the ONLY thing you had asked me at this point.

Your reply was and I quote:

I will not try to debate whose responsibility it is to set the proper ownership of a file that is created by UNiTE. 

Do you understand how that reads? It tells me that you don't know or care about how your server, the Docker container that you set up yourself, works. You are going to irrationally blame me for your wrong configuration. I explained once again how PHP works, something that is objectively outside the scope of our support.

It would be merely offensive if it stopped there. You then continue to change your question into something different, telling me about the content of the .htaccess content pretending that I said that this was outside the scope of our support. No, I didn't. I had only replied to the ownership because it wasn't right and it was caused by a server issue. Without this resolved I couldn't tell you anything more. I was also not told before what are its contents, which is very important for understanding your issue. Despite that, I did explain how UNiTE works and the conditions under which your issue could occur.

Before calling me a bully, after I have already helped you with your issue, please take a moment to assess your behaviour to me. I replied in a FAR LESS offensive tone than yours and only AFTER answering your question. If that makes me a bully, what does your behaviour and your doubling down on calling me names and making wrongful allegations make you?

As for your allegations about my behaviour, please let me say this. I know what I know and I know what I don't know. I do NOT expect people to know everything I do and I DO NOT talk people down just because they don't share my very particular domain-specific knowledge. When people are willing to learn more I go out of my way to help them, despite being outside the scope of our support. When people are behaving like entitled jerks, belittling me, being sarcastic, having irrational demands, retroactively misinterpreting my replies based on information they didn't share in advance or call me names I will respond in kind — after trying to address their technical issue.

In short, your experience of an interaction with me depends solely on how you treat me. It's called reciprocity.

If you are truly interested in resolving your issue, I am here to hold a further technical discussion. Let me remind you the relevant technical help points I made in my previous replies:

  • File ownership (user and group that owns the file) is controlled by the operating system. It will be the same user and group PHP runs under. Your use of su proved that point beyond any doubt.
  • File permissions are also controlled by the operating system. Check the default user mask for your user. How to do that depends on your Linux distribution.
  • When UNiTE starts extracting your site it writes a "stealth .htaccess" like Kickstart's eponymous option. This makes your site inaccessible to other people while the restoration is in progress. The .htaccess file is extracted as htaccess.bak. When UNiTE finishes the restoration successfully it will remove its .htaccess file and rename htaccess.bak to .htaccess just like Kickstart does.
  •  Based on the information you have provided so far one of the following happens:
    • UNiTE did not finish restoring the site. It tells you whether it's successful or not. Check its output.
    • You had a htaccess.bak file in your backup with these contents, backed up AFTER .htaccess itself. First the .htaccess is extracted as htaccess.bak. Then the "wrong" htaccess.bak is extracted, overwriting the previous file. At the end of the restoration the "wrong" file is renamed to .htaccess. You may want to check the backup log.
    • These were the contents of the .htaccess file of your site. This could happen if you had started a restoration with Kickstart but never ran the Clean Up step. Check the backup log.

If I were to make an educated guess, I would say that your UNiTE run did not finish successfully. This would explain why the stealth .htaccess file is left behind. So, let's take it from there and please treat me the way you'd like to be treated.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Saturday, 15 May 2021 20:17 CDT
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!