[Desktop-packages] [Bug 2054445] Re: Regresion in sssd backend configuration

2024-04-26 Thread Timo Aaltonen
SRU information missing from the description

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2054445

Title:
  Regresion in sssd backend configuration

Status in adsys package in Ubuntu:
  Fix Released

Bug description:
  This is a regression from when we added support for multiple AD
  backends (see https://github.com/ubuntu/adsys/pull/467)

  Previously adsys would use the first domain from `sssd.conf` and
  potentially override it if `ad_domain` is explicitly set for the
  domain, see:
  
https://github.com/ubuntu/adsys/blob/32a830f2a8204cc8b896094bad512ed619fbf6b7/internal/adsysservice/adsysservice.go#L279-L280

  The current implementation raises an error if we are not able to find
  an `ad_domain` setting in the domain section, even if we already have
  a domain (`sssdDomain`):
  
https://github.com/ubuntu/adsys/blob/c68d2cc999d25b1cb408a9e31775a76d2af4c8c7/internal/ad/backends/sss/sss.go#L62-L65

  Ideally we should set `domain` to `sssdDomain` if we cannot find a
  value for `ad_domain`, which will mimic the behavior previous to the
  refactor.

  While by default joining a domain with `realm join` will set the
  appropriate configuration values in `sssd.conf` so this doesn't
  happen, this is a regression we should aim to fix.

  ### Steps to reproduce it

  1. Join an AD domain with sssd (e.g. using `realm join`)
  2. Install the latest version of adsys, run `adsysctl update -m -vv`, 
everything should work
  3. Comment out the `ad_domain` line from `/etc/sssd/sssd.conf`
  4. `adsysctl update -m -vv` now fails, and the adsysd service does not start 
anymore
  5. (Optional) To confirm the functionality prior to the regression, 
re-attempt the steps above on Ubuntu 22.04 using the adsys version currently in 
the archive (0.9.2) -- adsys is able to correctly determine the domain even 
without the `ad_domain` setting.

  GitHub issue: https://github.com/ubuntu/adsys/issues/910

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2054445/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 2054445] Re: Regresion in sssd backend configuration

2024-03-28 Thread Launchpad Bug Tracker
This bug was fixed in the package adsys - 0.14.1

---
adsys (0.14.1) noble; urgency=medium

  * Pin Go toolchain to 1.22.1 to fix the following security vulnerabilities:
- GO-2024-2598
- GO-2024-2599
  * Update apport hook to include journal errors and package logs
  * CI and quality of life changes not impacting package functionality:
- Enable end-to-end tests in GitHub Actions
- Remove stale AD resources on test finish
- Add developer documentation for running end-to-end tests
- Collect and upload end-to-end test logs on failure
- Report test coverage in Cobertura XML format
- Silence gosec warnings using nolint and remove deprecated ifshort linter
- Use an environment variable to update golden files
- Bump github actions to latest:
  - azure/login
  - softprops/action-gh-release
  * Update dependencies to latest:
- github.com/charmbracelet/lipgloss
- github.com/golangci/golangci-lint
- github.com/golang/protobuf
- github.com/stretchr/testify
- golang.org/x/crypto
- golang.org/x/net
- google.golang.org/grpc
- google.golang.org/protobuf

adsys (0.14.0) noble; urgency=medium

  * Infer user KRB5CCNAME path via the libkrb5 API (LP: #2049061)
- This functionality is opt-in and activated if the detect_cached_ticket
  setting is set to true
- If the AD backend (e.g. sssd) doesn't export the KRB5CCNAME variable, 
adsys
  will now determine the path to the default ticket cache and use it during
  authentication (when adsys is executed through the PAM module) and runs of
  adsysctl update for the current user.
  * Allow sssd backend to work without ad_domain being set (LP: #2054445)
  * Upgrade to Go 1.22
  * CI and quality of life changes not impacting package functionality:
- Pass token explicitly to Codecov action
- Fix require outside of main goroutine
- Mark function arguments as unused where applicable
  Thanks to Edu Gómez Escandell
- End to end test VM template creation updates
- Bump github actions to latest:
  - codecov/codecov-action
  - peter-evans/create-pull-request
  * Update dependencies to latest:
- github.com/charmbracelet/bubbles
- github.com/golangci/golangci-lint
- golang.org/x/crypto
- golang.org/x/net
- google.golang.org/grpc

 -- Gabriel Nagy   Thu, 21 Mar 2024 12:27:01
+0200

** Changed in: adsys (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2054445

Title:
  Regresion in sssd backend configuration

Status in adsys package in Ubuntu:
  Fix Released

Bug description:
  This is a regression from when we added support for multiple AD
  backends (see https://github.com/ubuntu/adsys/pull/467)

  Previously adsys would use the first domain from `sssd.conf` and
  potentially override it if `ad_domain` is explicitly set for the
  domain, see:
  
https://github.com/ubuntu/adsys/blob/32a830f2a8204cc8b896094bad512ed619fbf6b7/internal/adsysservice/adsysservice.go#L279-L280

  The current implementation raises an error if we are not able to find
  an `ad_domain` setting in the domain section, even if we already have
  a domain (`sssdDomain`):
  
https://github.com/ubuntu/adsys/blob/c68d2cc999d25b1cb408a9e31775a76d2af4c8c7/internal/ad/backends/sss/sss.go#L62-L65

  Ideally we should set `domain` to `sssdDomain` if we cannot find a
  value for `ad_domain`, which will mimic the behavior previous to the
  refactor.

  While by default joining a domain with `realm join` will set the
  appropriate configuration values in `sssd.conf` so this doesn't
  happen, this is a regression we should aim to fix.

  ### Steps to reproduce it

  1. Join an AD domain with sssd (e.g. using `realm join`)
  2. Install the latest version of adsys, run `adsysctl update -m -vv`, 
everything should work
  3. Comment out the `ad_domain` line from `/etc/sssd/sssd.conf`
  4. `adsysctl update -m -vv` now fails, and the adsysd service does not start 
anymore
  5. (Optional) To confirm the functionality prior to the regression, 
re-attempt the steps above on Ubuntu 22.04 using the adsys version currently in 
the archive (0.9.2) -- adsys is able to correctly determine the domain even 
without the `ad_domain` setting.

  GitHub issue: https://github.com/ubuntu/adsys/issues/910

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2054445/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp