@alikon At a first look it seems to me that the database section of the get configuration command doesn't include the options for database connection encryption.

added php cli/joomla.php config:get --group db

@alikon I've started to test a bit and it goes well up to now. But there is a mismatch between help text and how it really works for the config:get, and maybe we have that elswehere, too.

The help says Usage: php ./cli/joomla.php config:set <option> <value>, but you have to specify in fact <option>=<value>.

Hmm, php ./cli/joomla.php config:set dbencryption=1 seems not to work. I don't get any error message, but php ./cli/joomla.php config:get still shows dbencryption 0 after that.

Update: Same with other parameters like e.g. frontediting.

@richard67
there is not such a setting like frontediting in configuration.php

for the config:set dbencryption=1 command
i'm unable to reproduce your findings

@alikon You will not get this parameter frontediting on a newly installed J4. But if you login to backend and just save the Global Configuration, the parameter will be there;

richard@vmkubu02:~/lamp/public_html/joomla-cms-4.0-dev$ php ./cli/joomla.php config:get frontediting
 -------------- ------- 
  Option         Value  
 -------------- ------- 
  frontediting   1      
 -------------- ------- 

richard@vmkubu02:~/lamp/public_html/joomla-cms-4.0-dev

It’s one of these parameters obviously missing in the default configuration.php.

@alikon I again tested and it is still the same for php ./cli/joomla.php config:set dbencryption=1 here: I don't get the green OK message, and the value isn't changed.

Maybe it’s because I’m on Linux and you’re on Windows?

@alikon Are you sure you want my review? Would Michael not be better? My PHP skills are limited. Anyway I'll have a look later and will test.

i've made a full rewrite of the SetConfigurationCommand
reusing existing core code where possible and added the encrypted db connection settings
@richard67 i need you for the encrypted db connection part

P.S @mbabker can you have another look please

@alikon How can I help you with the dB encryption part? Just review? Or is there something else to be done? Or you need some testing instructions for that? Let me know and I’ll try to help.

Beside this, as my posts above for the frontediting parameter have shown, we have configuration parameters not going into the configuration.php until you save global configuration in backend for the first time. Not an issue of this PR. Question is shall this PR handle that somehow, and shall someone open an issue about that?

How can I help you with the dB encryption part?

reviewing and testing as you were the writers for that, who better than you ? ?

consider that at the GSoC 2018 time that part wasn't in the core yet

as my posts above for the frontediting parameter have shown, we have configuration parameters not going into the configuration.php until you save global configuration in backend

should be addressed now with the full rewrite

I just pulled this branch and typed the command
php ./cli/joomla.php config:set dbencryption=1.

Is this the same message you see @richard67

?
The command
php ./cli/joomla.php config: set list_limit = 120
was OK, expect the permissions of the configuration.php are changed.

Before: -rw-r--r-- 1 astrid astrid 3433 Apr 13 13:11 configuration.php
After: -r--r--r-- 1 astrid astrid 2158 Apr 13 14:33 configuration.php

@astridx No, that's not what I had, and it has nothing to do with this PR. It is desired behavior that you can't use database connection encryption when using localhost, because localhost defaults to a socket connection for the mysql clients, and database connection encryption doesn't work when using a socket connection. Therefore you will receive the same error message when trying to do that configuration in backend or when doing a new installation. The solution: Use "127.0.0.1" (or "::1" on an IP-V6 only network) to enforce a TCP connection, then you can also use encrypted connections to the local host ;-)

@astridx So for the reason stated in my previous comment, this is a useful good test: The implementation in this PR handles that attempt for a malconfiguration in the right way and shows the right error messages.

@astridx Permission change of configuration.php is standard, too. It happens also when you change something in global configuration in the backend and save it, at least I've observed that in past.

Hint for testers: To test the Joomla Update part you can patch the version number in ./libraries/src/Version.php to something lower, e.g. 4.0-alpha-12 or so, and then change the update channnel in the Joomla Update component's options to "Custom URL" and enter the URL for the 4.0 nightly builds. Then the cli command should find some update.

@richard67 Thank you for explaining.

I am one step futher.

php ./cli/joomla.php config:set host=127.0.0.1 was OK, too.

Now I get another message:

I think it is because in the "Check that we aren't setting wrong database configuration" we only have the changed value.

$data is there:

Array
(
    [dbencryption] => 1
)

That is why the other values int the array

$options = array(
			'driver'   => $data['dbtype'],
			'host'     => $data['host'],
			'user'     => $data['user'],
			'password' => $app->get('password'),
			'database' => $data['db'],
			'prefix'   => $data['dbprefix'],
		);

are not set.

@astridx The connection encryption settings van be a very tricky thing, and unfortunately we don't have documentation for that yet.

Another thing is that the MySQLi database driver doesn't give much error information, only "connection failed" . If you would change to MySQL (PDO) you might see more details.

Actual standard installations of MySQL or PostgreSQL support connection encryption with 1 way certificate validation out of the box. On PostgreSQL you have to switch in on on the server. If that is given, then dbencryption=1 should work as long as dbsslverifyservercert=false. But maybe your server hasn't encryption support switched on so that connecting fails.

Anyway, for testing if this PR allows to change configuration values I suggest to test other parameters than the db connection encryption stuff. E.g. if you have both MySQL and PDO clients available, you can change database type from mysqli to myslpdo ;-)

Thanks @richard67 . Do you think it makes sense to continue testing if there is a problem. I have to repeat the tests later, right? That's why I reported my findings here first.

@astridx It's fine that we test it while it is draft and just report back every possible issue we find. I think that was what @alikon wanted. Laster when it is ready for review, then sure, we have to test again, but this will be easier for us then as we already will know what to test how.

@alikon If you update this branch to latest 4.0-dev of the cms, the system tests will be able to pass. Could you do that? Or shall I help with it?

please do it for me
thanks

@alikon If you use a local git client or IDE, just pull the changes from your remote, then you local branch will be up to date, too.

I updated the document at https://docs.joomla.org/J4.x:CLI_Update to make the text (not images) in the examples consistent with the CLI syntax:
core:check-updates
php cli/joomla.php extension:install --path=<path_to_file>
php cli/joomla.php extension:install --url=<url_to_file>
The command site:down fails with errors on Windows 10 where the MySQL root user has a password, even though other CLI commands work:
[ERROR] Failed to save properties
[ERROR] Database connection test failed with the following error: 1045: Could not connect to database: Access
denied for user 'root'@'localhost' (using password: YES)
Database connection settings changes were
not saved.
Notice: Undefined index: dbencryption in C:\www\joomla4\libraries\src\Console\SetConfigurationCommand.php on line 398

[ERROR] Database connection test failed with the following error: 1045: Could not connect to database: Access denied for user 'root'@'localhost' (using password: YES)

@toivo This could be due to MySQL server configuration not allowing password authentication for user "root" coming from the "localhost" server.

Notice: Undefined index: dbencryption in C:\www\joomla4\libraries\src\Console\SetConfigurationCommand.php on line 398

@alikon This is something you should check. I might not have time for that before today evening or tomorrow.

@toivo P.S.: If you use MySQL 8 with a default installation, password authentication is not enabled by default for new users (or the root user created with the installation), as far as I remember. You have to enable that for the particular user.

@richard67 This is MySQL 5.7.23 and the root user has password, which is not applicable because the the site uses its own MySQL user to access the database, not root. Maybe the CLI script assumes that the user is root when the server is localhost? All the other CLI functions I tested work.

BTW, I was going to remove the section "Installing Joomla! via the CLI" from the document, if that is not going to be implemented.

@toivo The CLI should use the user defined in global configuration, so if you have a database specific user there (what I recommend instead of using root), the CLI should use that one.

@toivo are you on a pure windows 10 or under windows subsystem for linux?

BTW, I was going to remove the section "Installing Joomla! via the CLI" from the document, if that is not going to be implemented.

the installation part as per RL comment #21452 (comment) should be a stand-alone script

@richard67 - I did not specify any user when accessing CLI. Is there a way to authenticate, other than having access to the shell or command prompt?

@alikon - is #21452 going to produce a new installation function in the CLI or is that going to be totally separate and have its own documentation?

• my workstation is Windows 10 with Wampserver 3.2.0 with Apache 2.4.41, MySQL 5.7.23 and PHP 7.4.2, which environment I find useful. Could also test on Linux, LiteSpeed and PHP 7.4.4 if preferred.

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28666.}

• is #21452 going to produce a new installation function in the CLI or is that going to be totally separate and have its own documentation?

I'm afraid of not, maybe should be better to open a new issue for that task and set that as a release blocker if there are people that really care about CLI
and from my past experience no one care about CLI
<sarcasm>Hey it is not a template issue</sarcasm>

@toivo this should be (in my dreams) a general purpose environment feature, so all that we need is to have a fully understand on what is working and on what environment and what it is not working and where

@alikon The CLI facility looked already good when I tested all the commands except the config functions, including installation and uninstallation of Akeeba Backup. The CLI facility gives the option to speed up the installation of new sites by running a standard command line script.

@alikon - is #21452 going to produce a new installation function in the CLI or is that going to be totally separate and have its own documentation?

Yes this will probably be a standalone thing separately

The command site:down fails with errors on Windows 10 where the MySQL root user has a password, even though other CLI commands work:
[ERROR] Failed to save properties
[ERROR] Database connection test failed with the following error: 1045: Could not connect to database: Access denied for user 'root'@'localhost' (using password: YES)
Database connection settings changes were
not saved.
Notice: Undefined index: dbencryption in C:\www\joomla4\libraries\src\Console\SetConfigurationCommand.php on line 398

@alikon I can confirm @toivo 's findings above for the site:up and site:down commands.

I have no idea yet what is the reason for that.

@alikon It seems when using the site:down and site:up functions, the routine save in file administrator/components/com_config/src/Model/ApplicationModel.php is called with an empty $data parameter.

site:down and site:up are working now.

@alikon It seems the help text and how it works again became inconsistent, at least for the config:get with the group option:

Help text tells to use =, but it needs to use a space.

P.S.: For config:set it is ok, i.e. there documentation and function are consistent with = to be used.

@alikon Setting database connection encryption options works well here.

Hint for other testers: Beside the default (dbencryption=0), anything else than dbencryption=1 and dbsslverifyservercert=false is tricky to test due to the requirements of the particular database server and client regarding e.g. server name matching the name in the server certificate or ownership and permissions of certificate and key files. There is no documentation for that feature on the Joomla Docs website, but information on how database connection encryption options can be tested and links to documentation sites of the particular database types can be found in PR #27351 .

I've tested all options here with success. Spefiyfing empty values where possible clears that option to an empty string, e.g. for the dbsslcipher to change a previously entered value to empty.

@alikon For the help text inconsistency I've mentioned 2 comments above see alikon#68.

Another hint for testers: If you successfully have tested a core update to nightly build (with having patched libraries/src/Version.php before, if necessary, so that an update was found), then after the update the changes from this pull request (PR) are lost of course, so to continue to test it needs to apply the PR again after the update.

In my test of config on Wampserver group=mail works all right. The only issue I found was with smtpsecure=tls when Global Configuration has STARTTLS. I am using Gmail as SMTP server. All the other functions were working perfectly.

@toivo Maybe tls doesn't work with self-signed certificate? Sorry, I misunderstood.

I was trying to update the documentation but may have messed it up because nothing changed. Will still investigate how to do that properly.

One thing I am missing: There is a function to check for extension updates, but not for doing the extension update after an update for an extension has been found. This is not a mistake in this PR, it is also not in the specification for the original PR. If possible this function should be added with a new, future PR after this one here has been tested and finally been merged.

@toivo Can we consider the results you have posted above as a good test?

If so, could you mark your test result on the issue tracker here https://issues.joomla.org/tracker/joomla-cms/28666?

Just select the "Test this" button in the top left area of that page, then select the appropriate test result, e.g. "Tested successfully", with the check box for that result, and then finally use the "Submitt tes result" button a bit below.

Thanks for your contribution.

P.S. The last change was just a change of the help text, so previous tests are still valid.

I have tested this item ✅ successfully on 953c70f

Tested all commands listed in the description.

Tested in detail database configuration parameter changes, especially for connection encryption.

Hints for other testers about how I tested, e.g. about patching CMS version so that an update is found, you can find in my previous comments.

I have tested this item ✅ successfully on 953c70f

Tested ok

RTC

@alikon Is the revision comment by @wilsonge above resolved #28666 (comment)? if not: Could that be done with a future PR, or should I remove RTC and wait for changes?

BTW, the last versions in Nightly Builds are from 14 April. Are they not generated daily or is the daemon broken?

BTW, the last versions in Nightly Builds are from 14 April. Are they not generated daily or is the daemon broken?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28666.

@toivo They should be generated every night. I can confirm that the nightly build of tonight doesn't contain changes from yesterday which it should contain. I'll inform the CMS maintenance team.

@alikon Is the revision comment by @wilsonge above resolved #28666 (comment)? if not: Could that be done with a future PR, or should I remove RTC and wait for changes?

i think it could be done in a future PR, but i'll left to the RL the last word

i think it could be done in a future PR, but i'll left to the RL the last word

I think too it can be done with a future PR.

This will do as a starting point. Thanks!