GOsa 2.7 README
Information
GOsa is an LDAP administration frontend for user administration. It is NO GENERIC frontend to dictionary servers. Information is stored in the way the underlying concepts suppose them to be stored (i.e. people accounts are stored in "ou=people" subtrees, etc.) This can only be configured marginally.
Complete setups applying Kerberos, AFS, LDAP, Mail, Proxy and Fax setups are not trivial at all. You should be familiar with these components and with your UNIX installation, of course. This file is (and will not be) an introduction to any of these components. See INSTALL for a quick overview about what to do, to get the things up and running.
If you want to try out GOsa on an easy-to-install server, we recommend playing with a Debian Edu mainserver installation. The Debian Edu mainserver has GOsa pre-installed and set up out-of-the box.
Project Status
This project won't receive functional updates any time soon. We will create and merge fixes to keep GOsa² usable and secure if necessary. If you find a security issue or a bug feel free to raise an issue.
Translations
GOsa is not available in your native language? Just read on...
Translations (or i18n) in GOsa are done by the gettext library. As a
result, every set of translations is stored inside one directory
per language as a text file called messages.po
.
For GOsa, you've to differenciate between gosa-core and the various gosa-plugins. The core has its translation and every plugin has a seperate translation of its own, too.
GOsa core can be translated by taking a look at the locales/core
directory. Just take the messages.po
file and copy it to some other
location and put your translations into the msgstr fields of this file.
For more comfort, use programs like i.e. poedit to achieve this. You may
look at the de/LC_MESSAGES
for the way how it works.
If you're done with that, create a directory for your language using the
ISO shortcuts (i.e. es
for spain) with a subdirectory
LC_MESSAGES
. For, e.g., the Spanish translation this would be:
gosa-core/locales/core/es/LC_MESSAGES
Put the freshly translated Spanish messages.po
into this directory.
To test this, you've to deploy the messages.po
file in your running
copy of GOsa and run the update-gosa
command, to let GOsa merge the
translations. Then, make sure your Apache web server has locale support
or, in case of Debian, that the specific locale will be generated (via
dpkg-reconfigure locales).
For gosa-plugins, every plugin has a locales directory. Translation works like described for gosa-core.
Always run update-gosa
after you've added translations in order to
let GOsa compile and re-sync the translations.
Contribute Translations
You may want your translations to be included in the main GOsa
repository, then just file and issue
for the correct GOsa component and attach the .po
there.
Notes
Be sure that gosaUserTemplates
are not able to log into your server,
since they may have no password set. Example configs can be found in the
contrib directory.
Have fun!
Cajus Pollmeier pollmeier@gonicus.de
Template System
GOsa comes with a new theme and a simplified template system for plugins and HTML snippets.
The simplified template system makes it easier to transfer your new themes to all plugins. For this you need to organize your new plugin templates in a subfolder that has the name of the theme.
Also code snippets that produce visual output are now easy to customize using switch statements. There you need to add an expression with the name of the theme if needed.
Example:
Declare a variable for the theme name in your class or in scope of the function.
Initialize it with the function getThemeName()
from the include/functions.inc.
Now you can use it as in the example below.
switch (${ThemeVariableName}) {
case '{YourThemeName}':
code...
break;
default:
code...
break;
}
By default GOsa has the classic design from GOsa 2.7 and a new default design. The theme is still changed via gosa.conf.
Sebastian Sternfeld sternfeld@gonicus.de
Debug GOsa² core and plugins using Xdebug
DISCLAIMER: DO NOT, and I repeat DO NOT use this on production webservers! Enabling a debugger can easily lead to compromised data, data loss, Remote code execution and more! So please, use a isolated development server, without any important user data.
- Install the
php-xdebug
package on your GOsa² server by executing the following command:
Debian (9+): sudo apt install php-xdebug
This will automagically configure apache2 too.
More information: https://xdebug.org/docs/install
- Configure Xdebug:
sudo editor /etc/php/7.4/mods-available/xdebug.ini
(Debian)
zend_extension=xdebug.so
xdebug.profiler_enable_trigger = 1
xdebug.profiler_enable = 0
xdebug.profiler_out_dir = "/tmp"
xdebug.remote_enable = 1
xdebug.start_with_request = yes
xdebug.idekey = <REPLACE ME WITH IDE KEY ('VSCODE', 'PHPSTORM'…)>
xdebug.mode = debug
xdebug.client_host = "<REPLACE ME WITH DEV HOST IP>"
xdebug.client_port = 9003
xdebug.log = "/tmp/xdebug.log"
WARNING: Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to:
/tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg
You can also set up a port forwarding tunnel using SSH, if you're using two different machines (or a VM) to develop:
ssh user@remote-machine -R 9003:127.0.0.1:9003
Also please notice that, the Xdebug server connects to the IDE client! (Not the other way around!)
So the IDE client needs to listen at port 9003
in this example.
The IDE key depends on the IDE you're using. Visual Studio Code uses VSCODE
and PhpStorm uses PHPSTORM
.
But don't worry, most IDE's let you configure this though.
- Test your installation.
First restart apache2:
sudo systemctl restart apache2
Then test if Xdebug was installed successfully:
Execute php -v
, it should look similar to this:
PHP 7.4.25 (cli) (built: Oct 23 2021 21:53:50) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.25, Copyright (c), by Zend Technologies
with Xdebug v3.0.2, Copyright (c) 2002-2021, by Derick Rethans
- Install xdebug-helper extension on your development browser.
Your internet browser needs to sent a specific header to the server to indicate a debugging session. This can be done easily using an extension. Luckily there are already easy to use extensions for Firefox and Chrome.
https://github.com/BrianGilbert/xdebug-helper-for-firefox)
https://github.com/BrianGilbert/xdebug-helper-for-chrome)
- Configure your IDE (Visual Studio Code in this example)
-
Install
PHP Debug
extension: https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug -
Configure VS Code to properly launch a PHP debug session.
Example .vscode/launch.json
:
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003,
// server -> local
"pathMappings": {
"/usr/share/gosa/plugins/": "${workspaceRoot}",
},
"postDebugTask": "sleep-task",
"log": true,
},
]
}
The pathMappings
setting is VERY important and helpful!
Imagine you work on ~/dev/test.php
and your Apache2 webserver
is configured to use /var/www/html/(test.php)
. Your IDE will report any breakpoints
using path ~/dev/test.php
. But the Xdebug server won't find any files under
~/dev/test.php
since it's a different machine!
pathMappings
maps ~/dev
to /var/www/html
and vice-versa.
Also you have to keep your local files and the server files in sync! This can be archived by using a SSHFS mount to develop directly on the server's files.
sshfs <local-mount-dir> root@<remote-server-ip>:/var/www/html
Also the xdebug client inside of VS Code can sometimes be slow to restart, so wait a bit after closing this debug session:
.vscode/tasks.json
:
{
"version": "2.0.0",
"tasks": [
{
"label": "sleep-task",
"command": "sleep 0.5s",
"type": "shell",
"presentation": {
"reveal": "never"
},
}
]
}