Problem with modules #10

Open
opened 11 months ago by meaz · 3 comments
meaz commented 11 months ago
Owner

After talking with Zash, I'm kind of lost on the reason why we set two plugin paths in the config file:

 -- These paths are searched in the order specified, and before the default path
    plugin_paths = { "{{ prosody_core_modules_path }}","{{ prosody_community_modules_path }}" }
    

where:

prosody_core_modules_path: "/usr/lib/prosody/modules/"
prosody_community_modules_path: "/usr/lib/prosody-modules"

I think it is because some mods were both in core and community mod, and we wanted to be sure that core ones would have precedence over the community ones. Is that correct?

Not related, but I also found a problem: we have now community modules in:

  • /usr/lib/prosody/modules/: not normal.
  • /usr/lib/prosody/prosody-modules: not normal.
  • /usr/lib/prosody-modules: normal, match our role.

Perhaps those errors come from a previous issue with our role? I think we should remove those. Pretty easy for /usr/lib/prosody/prosody-modules, but for /usr/lib/prosody/modules/ we need to pay attention as there are also core modules in it.

After talking with Zash, I'm kind of lost on the reason why we set two plugin paths in the config file: ``` -- These paths are searched in the order specified, and before the default path plugin_paths = { "{{ prosody_core_modules_path }}","{{ prosody_community_modules_path }}" } ``` where: ``` prosody_core_modules_path: "/usr/lib/prosody/modules/" prosody_community_modules_path: "/usr/lib/prosody-modules" ``` I think it is because some mods were both in core and community mod, and we wanted to be sure that core ones would have precedence over the community ones. Is that correct? Not related, but I also found a problem: we have now community modules in: - `/usr/lib/prosody/modules/`: not normal. - `/usr/lib/prosody/prosody-modules`: not normal. - `/usr/lib/prosody-modules`: normal, match our role. Perhaps those errors come from a previous issue with our role? I think we should remove those. Pretty easy for `/usr/lib/prosody/prosody-modules`, but for `/usr/lib/prosody/modules/` we need to pay attention as there are also core modules in it.
Poster
Owner

BTW the core modules are:
adhoc
mod_admin_adhoc.lua
mod_admin_shell.lua
mod_admin_socket.lua
mod_admin_telnet.lua
mod_announce.lua
mod_auth_anonymous.lua
mod_auth_cyrus.lua
mod_auth_insecure.lua
mod_auth_internal_hashed.lua
mod_auth_internal_plain.lua
mod_authz_internal.lua
mod_blocklist.lua
mod_bosh.lua
mod_c2s.lua
mod_carbons.lua
mod_component.lua
mod_csi.lua
mod_csi_simple.lua
mod_debug_sql.lua
mod_dialback.lua
mod_disco.lua
mod_external_services.lua
mod_groups.lua
mod_http_errors.lua
mod_http_file_share.lua
mod_http_files.lua
mod_http.lua
mod_iq.lua
mod_lastactivity.lua
mod_legacyauth.lua
mod_limits.lua
mod_mam
mod_message.lua
mod_mimicking.lua
mod_motd.lua
mod_muc_mam.lua
mod_muc_unique.lua
mod_net_multiplex.lua
mod_offline.lua
mod_pep.lua
mod_pep_plus.lua
mod_pep_simple.lua
mod_ping.lua
mod_posix.lua
mod_presence.lua
mod_private.lua
mod_proxy65.lua
mod_pubsub
mod_register_ibr.lua
mod_register_limits.lua
mod_register.lua
mod_roster.lua
mod_s2s_auth_certs.lua
mod_s2s_bidi.lua
mod_s2s.lua
mod_saslauth.lua
mod_scansion_record.lua
mod_server_contact_info.lua
mod_stanza_debug.lua
mod_storage_internal.lua
mod_storage_memory.lua
mod_storage_none.lua
mod_storage_sql.lua
mod_storage_xep0227.lua
mod_time.lua
mod_tls.lua
mod_tokenauth.lua
mod_turn_external.lua
mod_unknown.lua
mod_uptime.lua
mod_user_account_management.lua
mod_vcard4.lua
mod_vcard_legacy.lua
mod_vcard.lua
mod_version.lua
mod_watchregistrations.lua
mod_websocket.lua
mod_welcome.lua
mod_windows.lua
muc

**BTW the core modules are:** adhoc mod_admin_adhoc.lua mod_admin_shell.lua mod_admin_socket.lua mod_admin_telnet.lua mod_announce.lua mod_auth_anonymous.lua mod_auth_cyrus.lua mod_auth_insecure.lua mod_auth_internal_hashed.lua mod_auth_internal_plain.lua mod_authz_internal.lua mod_blocklist.lua mod_bosh.lua mod_c2s.lua mod_carbons.lua mod_component.lua mod_csi.lua mod_csi_simple.lua mod_debug_sql.lua mod_dialback.lua mod_disco.lua mod_external_services.lua mod_groups.lua mod_http_errors.lua mod_http_file_share.lua mod_http_files.lua mod_http.lua mod_iq.lua mod_lastactivity.lua mod_legacyauth.lua mod_limits.lua mod_mam mod_message.lua mod_mimicking.lua mod_motd.lua mod_muc_mam.lua mod_muc_unique.lua mod_net_multiplex.lua mod_offline.lua mod_pep.lua mod_pep_plus.lua mod_pep_simple.lua mod_ping.lua mod_posix.lua mod_presence.lua mod_private.lua mod_proxy65.lua mod_pubsub mod_register_ibr.lua mod_register_limits.lua mod_register.lua mod_roster.lua mod_s2s_auth_certs.lua mod_s2s_bidi.lua mod_s2s.lua mod_saslauth.lua mod_scansion_record.lua mod_server_contact_info.lua mod_stanza_debug.lua mod_storage_internal.lua mod_storage_memory.lua mod_storage_none.lua mod_storage_sql.lua mod_storage_xep0227.lua mod_time.lua mod_tls.lua mod_tokenauth.lua mod_turn_external.lua mod_unknown.lua mod_uptime.lua mod_user_account_management.lua mod_vcard4.lua mod_vcard_legacy.lua mod_vcard.lua mod_version.lua mod_watchregistrations.lua mod_websocket.lua mod_welcome.lua mod_windows.lua muc
Owner

Yes we have both paths to prevent community modules loading instead of core ones. We changed that after actually talking to Mattj and Zash and that was their suggestion. I dont understand the other question though. Core modules are installed by package while community modules by us so that path we could easily change if that's needed.

Sure, let's follow the suggested path for community modules and let's seperate them from core (I think that was mistake we did before we started using ansible and it was the way we have initially installed prosody in).
I would suggest changing the paths in prosody role. In production, what we could do is just deploy new container in parallel, run the role to make sure everything works as expected and then just swap containers. This will generate short downtime (probably not longer then two minutes) and will allow us to do the job wuickly and clean (without need to manually remove modules etc). I could prepare container already for it.

Yes we have both paths to prevent community modules loading instead of core ones. We changed that after actually talking to Mattj and Zash and that was their suggestion. I dont understand the other question though. Core modules are installed by package while community modules by us so that path we could easily change if that's needed. Sure, let's follow the suggested path for community modules and let's seperate them from core (I think that was mistake we did before we started using ansible and it was the way we have initially installed prosody in). I would suggest changing the paths in prosody role. In production, what we could do is just deploy new container in parallel, run the role to make sure everything works as expected and then just swap containers. This will generate short downtime (probably not longer then two minutes) and will allow us to do the job wuickly and clean (without need to manually remove modules etc). I could prepare container already for it.
Poster
Owner

I would suggest changing the paths in prosody role.

In role, we have:

prosody_core_modules_path: "/usr/lib/prosody/modules/"
prosody_community_modules_path: "/usr/lib/prosody-modules"

so we're good, if I get it correctly

In production, what we could do is just deploy new container in parallel, run the role to make sure everything works as expected and then just swap containers.

That would be awesome. Could we perhaps try to set a time so that you could show me how to do this?

> I would suggest changing the paths in prosody role. In role, we have: ``` prosody_core_modules_path: "/usr/lib/prosody/modules/" prosody_community_modules_path: "/usr/lib/prosody-modules" ``` so we're good, if I get it correctly > In production, what we could do is just deploy new container in parallel, run the role to make sure everything works as expected and then just swap containers. That would be awesome. Could we perhaps try to set a time so that you could show me how to do this?
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.