Migration to 5.0 breaking LDAP and SAML login

MrGeneration · October 5, 2021, 8:46am

Please help me to understand at which part the documentation should be improved or why I should continue to write it:
https://docs.zammad.org/en/latest/install/update.html

olivierlambert · October 5, 2021, 8:55am

I followed the doc instructions

Updating with a local account available give me a red login alert (to rule out LDAP/SSO right now):

PG::NotNullViolation: ERREUR: une valeur NULL viole la contrainte NOT NULL de la colonne « activity<u>stream</u>type_id » DETAIL: La ligne en échec contient (22099, null, null, null, null, 42, 42, 2021-10-05 08:53:20.523, 2021-10-05 08:53:20.525)

It’s in French but in plain English it should be something like:

PG::NotNullViolation: ERROR: a NULL value violates the NOT NULL constraintof the row "activity<u>stream</u>type_id" DETAIL: The failing line contains (22099, null, null, null, null, 42, 42, 2021-10-05 08:53:20.523, 2021-10-05 08:53:20.525)

I also tried to:

    systemctl stop zammad
    zammad run rails Cache.clear
    zammad run rake db:migrate
    systemctl start zammad

After the initial update, but same result.

Hope this helps. On my side, I’ll just wait a bit (probably tonight) to get more logs while doing tests. I might also clone the VM to do it.

ado123 · October 5, 2021, 9:22am

Sorry, I promise i will do better next time.
The relevant part of the production log is:
, [2021-10-05T10:54:57.972900 #2025-174280] INFO – : Processing by SessionsController#show as JSON
I, [2021-10-05T10:54:57.972955 #2025-174280] INFO – : Parameters: {“fingerprint”=>"-1840476201"}
E, [2021-10-05T10:54:57.992987 #2025-174280] ERROR – : PG::NotNullViolation: FEHLER: NULL-Wert in Spalte »activity_stream_type_id« verletz
t Not-Null-Constraint
DETAIL: Fehlgeschlagene Zeile enthält (52919, null, null, null, null, 622, 622, 2021-10-05 08:54:57.988244, 2021-10-05 08:54:57.991).
(ActiveRecord::NotNullViolation)
app/models/activity_stream.rb:82:in add' app/models/application_model/can_activity_stream_log.rb:46:in activity_stream_log’
app/controllers/sessions_controller.rb:228:in initiate_session_for' app/controllers/sessions_controller.rb:42:in show’
app/controllers/application_controller/has_download.rb:21:in block (4 levels) in <module:HasDownload>' app/controllers/application_controller/has_download.rb:20:in block (3 levels) in module:HasDownload’
app/controllers/application_controller/has_download.rb:19:in block (2 levels) in <module:HasDownload>' app/controllers/application_controller/handles_transitions.rb:16:in handle_transaction’
I, [2021-10-05T10:54:57.996424 #2025-174280] INFO – : Completed 422 Unprocessable Entity in 23ms (Views: 0.1ms | ActiveRecord: 3.6ms | All
ocations: 9800)

rolfschmidt · October 5, 2021, 9:23am

Hi @olivierlambert and @ado123 ,

can you try to run the following commands on your zammad run rails c to see what they return. Here an example of my dev system:

[1] pry(main)> TypeLookup.all
  TypeLookup Load (0.4ms)  SELECT "type_lookups".* FROM "type_lookups"
=> [#<TypeLookup:0x000055d043009768 id: 1, name: "session started", created_at: Mon, 04 Oct 2021 09:20:18 UTC +00:00, updated_at: Mon, 04 Oct 2021 09:20:18 UTC +00:00>,
 #<TypeLookup:0x000055d0430094c0 id: 2, name: "update", created_at: Mon, 04 Oct 2021 14:22:14 UTC +00:00, updated_at: Mon, 04 Oct 2021 14:22:14 UTC +00:00>,
 #<TypeLookup:0x000055d043009380 id: 3, name: "create", created_at: Mon, 04 Oct 2021 14:22:14 UTC +00:00, updated_at: Mon, 04 Oct 2021 14:22:14 UTC +00:00>]
[2] pry(main)> TypeLookup.by_name('update')
  TypeLookup Load (0.5ms)  SELECT "type_lookups".* FROM "type_lookups" WHERE "type_lookups"."name" = $1 LIMIT $2  [["name", "update"], ["LIMIT", 1]]
=> 2
[3] pry(main)> TypeLookup.by_name('create')
  TypeLookup Load (0.3ms)  SELECT "type_lookups".* FROM "type_lookups" WHERE "type_lookups"."name" = $1 LIMIT $2  [["name", "create"], ["LIMIT", 1]]
=> 3
[4] pry(main)> TypeLookup.by_name('session started')
  TypeLookup Load (0.6ms)  SELECT "type_lookups".* FROM "type_lookups" WHERE "type_lookups"."name" = $1 LIMIT $2  [["name", "session started"], ["LIMIT", 1]]
=> 1

ado123 · October 5, 2021, 9:26am

Hi, is this what you wanted ?

Loading production environment (Rails 6.0.4.1)
2.7.0 :001 > TypeLookup.all
 => #<ActiveRecord::Relation [#<TypeLookup id: 1, name: "session started", created_at: "2017-10-06 13:49:50", updated_at: "2017-10-06 13:49:50">, #<TypeLookup id: 2, name: "create", created_at: "2017-10-06 14:24:58", updated_at: "2017-10-06 14:24:58">, #<TypeLookup id: 3, name: "update", created_at: "2017-10-06 14:25:00", updated_at: "2017-10-06 14:25:00">, #<TypeLookup id: 4, name: "reminder_reached", created_at: "2017-10-27 06:00:11", updated_at: "2017-10-27 06:00:11">, #<TypeLookup id: 5, name: "switch to", created_at: "2017-11-17 13:24:44", updated_at: "2017-11-17 13:24:44">, #<TypeLookup id: 6, name: "ended switch to", created_at: "2017-11-17 13:25:13", updated_at: "2017-11-17 13:25:13">]> 
2.7.0 :002 > TypeLookup.by_name('update')
 => 3 
2.7.0 :003 > TypeLookup.by_name('create')
 => 2 
2.7.0 :004 > TypeLookup.by_name('session started')
 => nil 
2.7.0 :005 >

rolfschmidt · October 5, 2021, 9:28am

Hi @ado123 ,

weird it should return the id normally. Can you try to run Cache.clear again on your rails shell and try TypeLookup.by_name('session started') again? Does it really have no impact?

ado123 · October 5, 2021, 9:31am

After clear this is the output

2.7.0 :002 > TypeLookup.by_name('session started')
 => 1

rolfschmidt · October 5, 2021, 9:32am

can you login again?

ado123 · October 5, 2021, 9:36am

Yes, now i could run apt-get install --reinstall zammad without error and everything seems to work.

MrGeneration · October 5, 2021, 9:37am

I guess that was due to incorrect updating method.
Any way, I’m keen to learn how @olivierlambert instance is doing.

olivierlambert · October 5, 2021, 9:51am

Okay let me try that Back in few minutes to tell you the outcome

olivierlambert · October 5, 2021, 10:04am

So I did the steps but even with a apt-get install --reinstall zammad I got the:

Caused by:
PG::NotNullViolation: ERREUR:  une valeur NULL viole la contrainte NOT NULL de la colonne « activity_stream_type_id »

irb(main):001:0> TypeLookup.all
=> #<ActiveRecord::Relation [#<TypeLookup id: 1, name: "session started", created_at: "2020-12-15 10:39:04", updated_at: "2020-12-15 10:39:04">, #<TypeLookup id: 2, name: "create", created_at: "2020-12-15 10:43:39", updated_at: "2020-12-15 10:43:39">, #<TypeLookup id: 3, name: "update", created_at: "2020-12-15 10:43:39", updated_at: "2020-12-15 10:43:39">, #<TypeLookup id: 4, name: "switch to", created_at: "2020-12-15 10:50:27", updated_at: "2020-12-15 10:50:27">, #<TypeLookup id: 5, name: "ended switch to", created_at: "2020-12-15 10:50:54", updated_at: "2020-12-15 10:50:54">, #<TypeLookup id: 6, name: "escalation", created_at: "2020-12-15 13:50:47", updated_at: "2020-12-15 13:50:47">, #<TypeLookup id: 7, name: "escalation_warning", created_at: "2020-12-15 13:50:47", updated_at: "2020-12-15 13:50:47">, #<TypeLookup id: 8, name: "completed", created_at: "2021-02-10 21:24:33", updated_at: "2021-02-10 21:24:33">, #<TypeLookup id: 9, name: "reminder_reached", created_at: "2021-02-17 13:14:56", updated_at: "2021-02-17 13:14:56">]>
irb(main):002:0> TypeLookup.by_name('update')
=> nil
irb(main):003:0> TypeLookup.by_name('create')
=> 2
irb(main):004:0> TypeLookup.by_name('session started')
=> 1
irb(main):005:0> Cache.clear

However, after a BIG Cache.clear output, this time:

irb(main):006:0> TypeLookup.all
=> #<ActiveRecord::Relation [#<TypeLookup id: 1, name: "session started", created_at: "2020-12-15 10:39:04", updated_at: "2020-12-15 10:39:04">, #<TypeLookup id: 2, name: "create", created_at: "2020-12-15 10:43:39", updated_at: "2020-12-15 10:43:39">, #<TypeLookup id: 3, name: "update", created_at: "2020-12-15 10:43:39", updated_at: "2020-12-15 10:43:39">, #<TypeLookup id: 4, name: "switch to", created_at: "2020-12-15 10:50:27", updated_at: "2020-12-15 10:50:27">, #<TypeLookup id: 5, name: "ended switch to", created_at: "2020-12-15 10:50:54", updated_at: "2020-12-15 10:50:54">, #<TypeLookup id: 6, name: "escalation", created_at: "2020-12-15 13:50:47", updated_at: "2020-12-15 13:50:47">, #<TypeLookup id: 7, name: "escalation_warning", created_at: "2020-12-15 13:50:47", updated_at: "2020-12-15 13:50:47">, #<TypeLookup id: 8, name: "completed", created_at: "2021-02-10 21:24:33", updated_at: "2021-02-10 21:24:33">, #<TypeLookup id: 9, name: "reminder_reached", created_at: "2021-02-17 13:14:56", updated_at: "2021-02-17 13:14:56">]>
irb(main):007:0> TypeLookup.by_name('update')
=> 3
irb(main):008:0> TypeLookup.by_name('create')
=> 2
irb(main):009:0> TypeLookup.by_name('session started')
=> 1

Now it worked! Without reinstall, instantly. So clearly, Cache.clear in the CLI fixed it.

olivierlambert · October 5, 2021, 10:06am

However, the Dashboard is broken (error in the browser console, like App.n(error) | executeSingel task: Dashboard ReferenceError: item is not defined).

Should I reboot?

olivierlambert · October 5, 2021, 10:13am

@ado123 can you access the Dashboard?

I can’t access it:

App.n(error)                   | executeSingel task: Dashboard ReferenceError: item is not defined
    this.JST["app/views/dashboard/activity_stream_item"]/</< https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:62
    this.JST["app/views/dashboard/activity_stream_item"]/< https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:62
    "app/views/dashboard/activity_stream_item" https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:62
    view https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:22
    renderItem https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:27
    s https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:27
    renderAll https://myURL.fr/assets/application-c89a4b0492e6b805dc3cd202300f32ff5748db169bff72b0b69f339bc31adba0.js:27
    s https://myURL.fr/assets/
[...]

edit: SSO with SAML works, but not the LDAP login anymore. Internal user is OK

olivierlambert · October 5, 2021, 10:18am

Okay got it WORKING!!!

I had to do the apt-get install --reinstall zammad after the Cache.clear otherwise the database migration wasn’t complete.

Thanks @ado123 @MrGeneration and @rolfschmidt

tomsparrow · October 5, 2021, 10:49am

Hi,
I had the same problem on our instance, fortunately I managed to fix it using the instructions here and also since I have two instances running I tried again with the second - the problem seems to be mostly/entirely on not clearing the cache before upgrading.

On the install instructions:
Step 4: Clear Zammad cache

$ zammad run railsr "Cache.clear"

produces

sh: 1: exec: railsr: not found

(extra r after rails) and the presumably correct zammad run rails "Cache.clear" or zammad run rails Cache.clear both product the following:

rails aborted!
Don’t know how to build task ‘Cache.clear’ (See the list of available tasks with rails --tasks)
Did you mean? tmp:cache:clear
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/railties-5.2.4.6/lib/rails/commands/rake/rake_command.rb:23:in block in perform' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/railties-5.2.4.6/lib/rails/commands/rake/rake_command.rb:20:in perform’
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/railties-5.2.4.6/lib/rails/command.rb:48:in invoke' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/railties-5.2.4.6/lib/rails/commands.rb:18:in ’
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in require' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in block in require_with_bootsnap_lfi’
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/loaded_features_index.rb:65:in register' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:20:in require_with_bootsnap_lfi’
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:29:in require' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.4.6/lib/active_support/dependencies.rb:291:in block in require’
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.4.6/lib/active_support/dependencies.rb:257:in load_dependency' /opt/zammad/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.4.6/lib/active_support/dependencies.rb:291:in require’
/opt/zammad/bin/rails:9:in `’
(See full trace by running task with --trace)

However, running zammad rails run c followed by Cache.clear seemed to produce no errors (though a lot of output - tmp files it’s presumably clearing out).

After this, running the package update (apt in my case) ran correctly, with DB migrations and resulted in a working install. The problem with the process seems to be the instruction to clear the cache not working - the instructions have a typo in them, but even without that there is an error on both my systems at least.

MrGeneration · October 5, 2021, 10:53am

tomsparrow:

$ zammad run railsr "Cache.clear"
produces
sh: 1: exec: railsr: not found
(extra r after rails) and the presumably correct zammad run rails "Cache.clear" or zammad run rails Cache.clear both product the following:

Thanks for the hint.
Seems like I did have fat fingers again.

This is addressed by the following commit fix rails r typo · zammad/zammad-documentation@4e92988 · GitHub and currently running through CI. The documentation page affect should be updated within the next 5-15 minutes.

KINGRULZ · October 7, 2021, 5:35am

For me correct fixed was

zammad run rails r “Cache.clear”

then

apt-get install --reinstall zammad

jess_t · October 8, 2021, 9:29am

NEW SECURITY RELEASE: ZAMMAD 5.0.1

Hey everyone!
This is a quick shout-out to let you know that a few users with special constellations noticed an unwelcome change after upgrading to Zammad 5.0: They suddenly saw tickets in the Overview that belonged to groups they were not a part of. While the tickets as such were not accessible to them (they could only see the metadata), it still represents a flaw from a privacy and security perspective.

We have now created a Security Release that fixes this problem.
If you have already installed Zammad 5.0, please upgrade to 5.0.1 to ensure you don’t face the same issue.

All the details can be found in the Release Notes.

Thank you!

system · February 5, 2022, 9:30am

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.