Bram Matthys [Mon, 8 May 2023 06:29:04 +0000 (08:29 +0200)]
Deal quicker with dead event loop processes. End-users need to run 'composer install'.
Long story:
In the panel we have some background tasks, like the live "Network Overview", the
"Logs" live view, but also the notification that works on every page behind-the-scenes,
that will show popups for server errors/warnings.
Depending on the webserver and PHP backend, but in particular with fast cgi modules,
these PHP processes may not see the browser as being "gone" until they actually send
something, so we send something when $rpc->eventloop() returns, which is guaranteed to
return at least every 10 seconds (if there is no data, quicker otherwise).
This means that, until now, it took up to 10 seconds for these PHP processes to die.
If you are quickly browsing from one page to the other, then - especially with the
main overview or the logs page which causes 2 processes - you could hit your PHP max
processes or max workers, especially if you have a relatively low limit of like 10.
Upstream commit of unrealircd-rpc-php changes the returning behavior (when idle) from
every 10 seconds to every 2 seconds, which should help a lot.
If you still have situations where pages don't load at all or get max processes reached
in your webserver logs then you should really bump your PHP process/workers limit.
There's no way around that :).
Bram Matthys [Sun, 7 May 2023 17:24:45 +0000 (19:24 +0200)]
Fix Role Editor: make the role stuff db-independent (most code already was).
Get rid of the ROLE hooks at the same time, since they can all be accessed
via the generic config API, right ?
Bram Matthys [Sun, 7 May 2023 11:31:22 +0000 (13:31 +0200)]
Fix warning/error in channel sorting.
Reported by Madriix in https://github.com/unrealircd/unrealircd-webpanel/issues/30
Fix suggested by ghostnode on IRC.
Bram Matthys [Sat, 6 May 2023 17:28:04 +0000 (19:28 +0200)]
Apache w/FPM: workaround for pages hanging and becoming completely unresponsive.
Reported by Thoraxx.
And yeah, it would be better if users would reconfigure their fcgi proxy and
tweak apache conf with flushpackets=on but I think it is "too difficult" for
users. Ideally we would detect the condition and error or warn, but.. yeah...
if anyone has a better idea, or knows of a PHP trick to force flushpackets=on
at runtime, tell me :D
Bram Matthys [Fri, 5 May 2023 16:51:19 +0000 (18:51 +0200)]
Logs: you can now enter an IP address or nickid in the search field.
This because it now searches in all JSON data, include IP addresses,
nickid, nicks, hostnames, etc... makes it very easy to filter on
all events of a particular person or host.
Bram Matthys [Fri, 5 May 2023 13:00:18 +0000 (15:00 +0200)]
Logs: don't show join/part/kick in live view by default.
See comment...
/* Add these as well, they are not logged by default
* in the memory log either. See
* https://github.com/unrealircd/unrealircd/commit/45342c2d33968178cd07a12cd6fdc4e65b604134
* Added here separately because we may want to make
* this an option...
*/
Bram Matthys [Fri, 5 May 2023 11:02:18 +0000 (13:02 +0200)]
Log view: don't redraw when fetching 1000 log entries.
Instead, for historical logs, redraw every 100 events.
Then do an explicit redraw/sync. And then start the live ones.
Otherwise the CPU of the user browsing the panel is not happy :D
Channels: possibly fix a bug when clicking on a channel (loading wrong URL).
Reported by Nini.
Only happens when base_url was / and then due to my wrongly added /
it would result in a href to //channels/ etc... which is misinterpreted
as https://channels/details.php..etc...
Fetch existing logs in Log screen. Only for git unrealircd.
Or actually this isn't even committed yet....
Requires end users to run 'composer install' as well...
Start on "Logs" (log viewer). This only shows live logs at the moment.
Still to do:
* Click = all details
* Fetch past XYZ log entries (requires new unrealircd api call)
Since 'responsive' datatables were not working, i made it non-responsive
and did the responsiveness myself based on resolutions etc.
I kinda hate the manual fiddling but now it works great on mobile both
in landscape and portrait mode, and on various desktop resolutions.
Set "issuer" already in connection call. This to speed up connection
a bit as this causes unrealircd-rpc-php to skip a ping-pong and also
makes it not wait for the rpc.set_issuer call reply (since we don't
care that much).
Update composer dependencies. End users need to run 'composer install'.
This so 02da13a9d49686e9a6c6254c7318e3e145debbf3 actually works
(set "issuer" in UnrealIRCd\Connection options to save 1 round trip).
Note: if end-user forgets to call 'composer install' then this means
set by is not logged now.
server-bans: switch title and button value to default
This fixes an issue where the header and button text for the modal for "Add Ban" was still "Edit Ban" after having previously clicked a ban to edit and now clicked "Add Ban" again.
Overview: Make the "Live stats" only show if we have a live connection.
The "Live stats" will also automatically disappear if stats have not
been received past 10 seconds (we should receive it every 1sec).
TODO: Consider removing all values in such a scenario
TODO2: Consider showing a connection lost icon or something else..
Overview: use the live feed only, don't initially set anything.
This avoids duplicate code and also makes the page load faster
on high latency connections.
Channel list: Run StripControlCharacters() on the topic
The alternative would be irc2html() from
https://github.com/unrealircd/unrealircd-webpanel/pull/24
but not so sure about that... it makes colors and other markup
done by random users show quite prominently on an admin panel.
Make API pages return empty data / die when server is not available.
This fixes annoying JS popup in "Users" and "Server bans" when the
IRC server is down.
Add simple way to deal with IRC server configuration required.
This handles the "no_irc_server_required" property on $pages.
Also renames "url" property to "script" in $pages in previous commit,
since it points to the script page (eg server-bans/index.php).
It will automatically strip /index.php if possible.
Use responsive datatables in Users view: automatic column priority etc.
* Actually in mobile this seems to have a glitch, it shows one column too
much, which corrects itself as soon as you scroll.
* On a big screen the "Oper" and "Secure" columns are still not shown
even though they could be. Then again, those columns are not really
important so may be scratched altogether.
* If all this turns out not to work too well, then we can always revert
revert the changes to users/index.php, i guess.
Disable autocomplete in setup pages for user/password of SQL and RPC as these
have nothing to do with the web login so it is only confusing.
Still allow autocomplete for the "Create account" thing though, eg for devs
doing repeated setups.
unrealircd::rpc_password is now encrypted with secret::key (XChaCha20-Poly1305-IETF)
Again, the purpose is so if any bad person gets a copy of your DB then the
stored RPC password is still useless since they also need your config/config.php.
Old unencrypted unrealircd::rpc_password entries are automatically
encrypted (upgraded).
Similar to previous commit 6b08fcb99e66665e7e4f345702915d7192fcd27b
this means you cannot blindly 'rm config/config.php' and then expect
your existing DB to still work with a random new (and different) key.
The config file now contains 'secrets' with 'pepper' that is used for
hashing passwords in the database. This means a hacker now needs to
have config.php to attack the (hashed) passwords in the database.
This may not be very meaningful if the DB backend is file_auth, but
can be useful for example if the backend is sql_auth and your database
backup (mysqldump) gets leaked.
We automatically create the secrets (like pepper) and automatically
upgrade password hashes to use pepper while each user logs in.
This does need write access to config/config.php while upgrading, though.
The hashed passwords in the database will have the prefix "peppered:"
if they have been upgraded to use pepper.
A side-effect of this is that you cannot blindly 'rm config/config.php'
and start the installation over again while keeping your old database.
This because the hashed passwords in the existing database were created
with an old pepper value and the new setup would create a random new
pepper value, making the hashes worthless (and wrong).
This mostly matters for devs though, but it is something for testers
to be aware of as well.