[OT] - remote assistance software
by Damiano Venturin
I'm sorry for the OT but I thought that some of you could spare me tons
of time.
Do you know any very good open source software for remote assistance
that runs on debian (my side) and windows > 7 (customer side). I need to
be able to control kbd and mouse and see customer's screen.
Depending on price I definitely consider paid versions and I would avoid
any cloud service (unless there is no other valid option) that I can not
control.
Time ago I used the google chrome extension but last time I used it gave
me troubles and, in any case, I would definitely go for something more
professional.
Thanks!
--
Damiano Venturin
https://dam.venturin.net
3 years, 6 months
New DebOps release: v2.2.0
by Maciej Delmanowski
Hello everyone,
This release is way overdue (previous one was 6 months ago!) due to some
personal reasons. I'm sorry about the delay and I hope that it won't happen
again. So, without further ado...
New DebOps release, v2.2.0
--------------------------
You can find the new version of DebOps on:
GitHub: https://github.com/debops/debops/releases/tag/v2.2.0
PyPI: https://pypi.python.org/pypi/debops/2.2.0
Galaxy: https://galaxy.ansible.com/debops/debops/
You can upgrade the Python-based installation by running the command:
pip3 install --upgrade debops
Installation instructions can be found here:
https://docs.debops.org/en/stable-2.2/introduction/install.html
The brief Changelog can also be found on the documentation page:
https://docs.debops.org/en/stable-2.2/news/changelog.html
Complete, detailed changelog can be viewed using the 'git log' command.
You can use the 'git log --no-merges' command to skip the "boring" merge
commits.
The DebOps documentation has a separate page which details important
changes from previous release in the Ansible inventory or on the remote
hosts which you might need to perform manually:
https://docs.debops.org/en/stable-2.2/news/upgrades.html
The Python packages available on PyPI, as well as the tarballs available
on GitHub are signed with my GPG key. You can get it from the OpenPGP
keyserver network using the command:
gpg --keyserver hkp://pool.sks-keyservers.net \
--recv-keys 27067A91D620EE91D50309D92DCCF53E9BC74BEC
Currently there's a problem with updating the DebOps monorepo using
'debops-update' script, a fix will be available in the next patch release.
I wasn't able to finish the new DebOps scripts yet, so the v3.0.0 release is
delayed; check the documentation for the new planned release dates.
The v2.2.0 development cycle finished with ~357 commits (without merges),
pretty average so far. Here's a brakdown of committers this time around:
141 Maciej Delmanowski
80 Robin Schneider
39 Imre Jonk
24 Ellen Papsch
11 Gabriel Lewertowski
8 Tasos Alvas
7 Pedro Luis López Sánchez
6 Jérémy Gardais
5 Émile Morel
4 Ivan Diachenko
4 Patryk Ściborek
3 David Härdeman
3 Nicolas Quiniou-Briand
3 Stefan G. Weichinger
2 Bao Nguyen
2 Christoph Johannes Kleine
2 Jan Kowalsky
2 JoelKle
1 Andreas Palm
1 Andrew Rowson
1 Douglas Heriot
1 George Giannou
1 Keridos
1 Oz N Tiram
1 Reto Gantenbein
1 Sebastian Vaisov
1 Serge Victor
1 asyncopation
1 velvetant
Thanks for everyone for bugfixes, new functionalities andimprovements. See you
around in the commits next time!
Goals reached since previous release
------------------------------------
Unfortunately, the rewrite of the DebOps scripts took longer than I expected.
It was partly due to issues found with the LDAP directory, namely the
'mailservice' schema. Fixing that meant that the LDAP directories will have to
be rebuilt from scratch to support the schema changes, so I took the
opportunity to make some more intrusive changes and add a few more schemas;
check the Changelog for more details.
The switch to the Ansible Collection format hasn't happened yet as well; I want
to synchronize this with the new scripts which will support Ansible Collections
natively. That's why the major version number hasn't been increased.
The 'firewalld' role and support for the service hasn't been adde yet, but
I still have that in mind.
The 'stable-1.1' and 'stable-1.2' releases are retired
------------------------------------------------------
DebOps v1.1.0 was released on 25th August 2019 and had 12 patch releases with
about ~400 commits; most of these were backports from later releases. This
release introduced the `debops.keyring` role which has been used to manage APT
keys, repositories and GPG keys in other DebOps roles since. This release was
retired on 30th August 2020, but there was no annoucement since it was a patch
release only.
DebOps v1.2.0 was released on 1st Decemter 2019, and had 7 patch releases with
about ~322 commits since (small number of releases was due to long hiatus). The
v1.2 release brought a bunch of changes to the LDAP directory support, with
multiple roles gaining integration with the directory tree.
There will be no new updates to the 'stable-1.1' and 'stable-1.2' branche.
Existing users are encouraged to upgrade to newer DebOps releases, and to read
the upgrade notes for information about needed changes.
The next DebOps release to be retired will be 'stable-2.0', on 30th
June 2020. Due to the delay in the release schedule, the support for the
'stable-2.0' and 'stable-2.1' releases has been extended for 6 months each to
compensate for no versioned releases since.
New DebOps logo
---------------
The most visible change in the project is the new DebOps logo, created by Tasos
Alvas. Big thank you for the new design, Tasos! If you haven't seen it yet, you
can check it out on the documentation page, there's also archived issue
thread[1] about the design proposal with interesting comments.
Imre Jonk offered custom t-shirts with the DebOps logo to the most prominent
DebOps developers; the t-shirts should be arriving via the couriers shortly.
Big thanks for the gift, Imre!
[1]: https://github.com/debops/debops/issues/1541
New release highlights
----------------------
As usual, there are many interesting changes and new features in a DebOps
release. I suggest that you check out the Changelog of the latest release;
below you can find a list of highlights:
- Most of the Ansible handlers were moved from various roles to the
'global_handlers' role which will be used as a dependency. This should make
inter-service integration a bit easier since various service roles will not
have to be included in the playbooks to allow for reloads or restarts.
- There were many changes in the LDAP support thruought the project. The
support for OpenLDAP ACL tests was redesigned and the 'slapd' role now manages
the base directory structure. The default installation now includes schema
for FreeRADIUS as well as dynamic (groupOfURLs) and empty (groupOfEntries)
groups. There were also changes in existing schemas, mostly fixing bugs or
adding new attributes; these changes will require a rebuild of the existing
LDAP directories.
- Due to changes in the offering of Travis-CI, DebOps now uses GitHub Actions
for initial Continuous Integration support. GA is used for code linting and
build checks for Python packages and Ansible Galaxy collections.
Plans for the next development cycle
------------------------------------
My plans for the next release haven't really changed. I plan to rewrite the
DebOps scripts to improve support for the project directories and Ansible
Collection integration. When that happens, the DebOps repository will also
transform to be usable as an Ansible Collection - this will require changes in
the legacy Ansible roles and playbooks.
During the long hiatus from new releases I realized that the number of users
that rely on the tagged DebOps releases (Python package, Docker image, Ansible
Collection) is much larger than the users that use the git branches, either
'master' or 'stable-x.y' ones. This means that the release model will have to
somehow focus on the former more. Currently creating a new release is a mostly
manual process, perhaps some scripting and use of various APIs will improve
this in the future.
Once again, I'm sorry for the long delay, and I'll try to be more on schedule
the next time.
Maciej
3 years, 10 months
lookup plugin (task_src), again?
by philippe roud
Hi,
I use debops for quite some time now and recently updated to ansible
2.10.5. I got the :
/lookup plugin (task_src)fatal: [sentry_server]: FAILED! => {"msg":
"lookup plugin (task_src) not found"}/
in the past and solved it by adding the lookup_plugins to my "playbooks"
dir. But today it keep complaining about it for plays that use
role:users and role: resources.
I tried to symlink it in different places that appear in the ansible.cfg
but it doesn't help. I created a clean virtualenv and installed debops
with : pip install debops[ansible], but the result is the same, so the
error should be on my side...
Does anybody see something that I could have done wrong or forgot to update?
Best regards
PHiL
3 years, 11 months
Alias with several recipients in postldap
by Thomas Blein
Hello
I which you an happy new year. I would like to thank all of you for the
great job that is done in the Debops project. It provides a nice way to
manage a lot of classic/needed services.
I am currently setting up my mail service using the LDAP directory
('slapd', 'postfix', 'postldap' and 'postconf' roles). Following are my
comments/questions.
1. postldap role seems to have outdated default parameters
----------------------------------------------------------
I am the feeling that the documentation and the default settings in
'postldap' role do not correspond to the 'mailservice' schema setup by
'slapd' role. For example, the schema recommends to not use the 'mail'
attribute for delivery. However, in 'postldap' the query filter are:
query_filter: '(&
(objectClass=inetOrgPerson)
(|
(mail=%s)
(mailAlias=%s)
)
(|
(authorizedService=all)
(authorizedService=mail:receive)
)
)'
I manage to have a working system by correcting 'mail' with
'mailAddress' and 'mailAlias' with 'mailAlternateAddress'.
Am I right? I can propose a merge request if needed.
2. How to have several recipient for an address?
------------------------------------------------
The previous setup is working nicely if the address corresponds to a
unique final account, either as main address 'mailAddress' or a
secondary one 'mailAlternateAddress'.
However, if I want a unique address delivers to several accounts, it is
not possible. Indeed, 'mailAlternateAddress' rely on the 'mail'
attribute that is unique. I know how to setup it for local account with
'etc_aliases' role, but how to have it in the LDAP directory?
Thanks a lot for your help and suggestions.
All the best
Thomas
3 years, 11 months
