Ability for hosts to set a monthly flat host fee per Collective instead of a %

User story

I also want to be able to specify a plan rather than a fee.
Eg. Open Collective Brussels is asking €10/month to each collective. Right now they have just created a tier and they manually ask collectives to subscribe to it. It would be very useful if this could be part of the built-in experience.

Best solution for this problem
See design

MVP
Needs specs
Context
Follow up on https://github.com/opencollective/opencollective/issues/2821#issuecomment-584154676

Kind of a dup of #2843 but this is more narrowly scoped

Suggestion on the wording to make it more clear:
Host fees for [Collective]

Use default fee(then display whatever that is here, uneditable) (change fee for all Collectives (links to settings))
Custom percentage: [   %] of all income
Flat monthly flat fee: [$   ]

"Retainer" means something else so don't use that word.
Also: I think monthly fee should be an option in the global settings for the host as well.
Will hosts be seeing this screen from their dashboard with a list of their hosted Collectives, or will they access it by going to that Collective's page?

Another question: When we add funds manually there's an editable box for a custom % fee. I think we should keep this because the fee for the Collective might be one thing, while a specific agreement for that specific transaction could be another, but I'd love it if next to the % box on add funds there was also a one time flat rate fee option. "Add funds" should probably inherit as the default the global host fee if there's no per-Collective fee set, and the per-Collective fee if there is one, but still remain editable by the admin.

Bump! I really want to be able to set a per-month fee per Collective.

Very keen to see this happen. Bump.

This is a great feature! Would you consider adding a checkbox that gates collection of the retainer on activity? Something like:

[ ] Only if there is activity

This would allow for charging a retainer fee when there is activity in an Open Collective that month (e.g. expenses filed/paid out, incoming contributions). This would make open collective's model more attractive for small groups with sporadic activity (e.g. no monthly subscribers, periodic donations and occasional activity every couple months or only in certain times of the year).

This is a great feature! Would you consider adding a checkbox that gates collection of the retainer on activity? Something like:

[ ] Only if there is activity

This would allow for charging a retainer fee when there is activity in an Open Collective that month (e.g. expenses filed/paid out, incoming contributions). This would make open collective's model more attractive for small groups with sporadic activity (e.g. no monthly subscribers, periodic donations and occasional activity every couple months or only in certain times of the year).

could we update the ticket title? seems this about "per-collective host fee overrides (flat or %)"

bump - this is important to us - our bank balance & OC balance are out-of-whack.
fyi: our host charges twice a year (not monthly).
do "host fees" need to be handled any differently than any other charge?  shouldn't they generate a ledger entry when they are charged?

I'm bumping this too. It's had the important tag on it for a while now, and Hosts keep asking for it. @znarf can it at least be scoped please?

could we update the ticket title? seems this about "per-collective host fee overrides (flat or %)"

@patcon Per-collective host fee overrides as a percentage is already possible from the host dashboard. This issue is only about the second option, being able to set a fixed monthly retainer instead.

Please don't call it a "retainer". That word has a different meaning in English. Let's call this a "monthly flat fee".

This continues to be requested.

had this requested in a recent call with a potential fiscal host. They charge a flat monthly fee


Add files via upload

Added the python solution for Valid Parantheses problem.

thanks, @CyberSaiyam for contributing. Please go through the contribution guidelines for further contributions. I will merge your PR soon.
Please contribute to other solutions as well.


When object is out of FOV & re-appear, Rpi object tracking is not resuming

rpi-deep-pantilt version: 1.2
Python version: 3.7.3
TensorFlow version: 2.2
Operating System: Buster 8-20-2020

Description
Describe what you were trying to get done;
I tried to make RDP track face continueously with Edge TPU on Pi4 8GB with clean install only with RDP and I expected tracking would resume when subject re-appear in FOV but it hangs.
Tell us what happened, what went wrong, and what you expected to happen.;
When I run (.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu face,
As long as subject is in FOV, it works but when subject goes out of FOV, within in 10 second, cam is pointing up toward ceiling or facing down and stuck in there -- no tracking resume
When I run with (.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu person,
As long as subject is in FOV, it works but when subject goes out of FOV, cam remain toward position of last jitter up & down and when subject return within FOV, cam is stuck pointing toward last position &  stuck in there. -- no tracking resume
Paste the command(s) you ran and the output.
(.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu face
(.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu person

If there was a crash, please include the traceback here.

No Crash but,
Upon use of face label;
(.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu face
^C[INFO] You pressed ctrl + c! Exiting...
[INFO] You pressed ctrl + c! Exiting...
Process Process-2:
[INFO] You pressed ctrl + c! Exiting...
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/.venv/lib/python3.7/site-packages/rpi_deep_pantilt/detect/camera.py", line 38, in run_pantilt_detect
prediction = model.predict(frame)
File "/home/pi/.venv/lib/python3.7/site-packages/rpi_deep_pantilt/detect/facessd_mobilenet_v2.py", line 139, in predict
input_tensor = input_tensor[tf.newaxis, ...]
File "/home/pi/.venv/lib/python3.7/site-packages/tensorflow/python/ops/array_ops.py", line 944, in _slice_helper
new_axis_mask |= (1 << index)
KeyboardInterrupt
Aborted!
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/popen_fork.py", line 28, in poll
pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
Upon use of Person label;
(.venv) pi@raspberrypi:~ $ rpi-deep-pantilt track --edge-tpu person
^C[INFO] You pressed ctrl + c! Exiting...
[INFO] You pressed ctrl + c! Exiting...
[INFO] You pressed ctrl + c! Exiting...
Aborted!
Process Process-2:
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/.venv/lib/python3.7/site-packages/rpi_deep_pantilt/detect/camera.py", line 38, in run_pantilt_detect
prediction = model.predict(frame)
File "/home/pi/.venv/lib/python3.7/site-packages/rpi_deep_pantilt/detect/ssd_mobilenet_v3_coco.py", line 160, in predict
self.tflite_interpreter.invoke()
File "/home/pi/.venv/lib/python3.7/site-packages/tflite_runtime/interpreter.py", line 506, in invoke
self._interpreter.Invoke()
File "/home/pi/.venv/lib/python3.7/site-packages/tflite_runtime/interpreter_wrapper.py", line 118, in Invoke
return _interpreter_wrapper.InterpreterWrapper_Invoke(self)
KeyboardInterrupt
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/popen_fork.py", line 28, in poll
pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
Am I missing any component or applying wrong command?

Thank you for reporting this @Martin2kid, sorry about the behavior here being difficult to debug. I'm guessing the default PID gains do not work for the distance or relative angle of the camera to tracking target in your setup. Another possibility is that your camera needs to be rotated (--rotation <int>). The default rotation values match the camera orientation in this picture:

In 2.0 (target: end of year), I'm shipping a rework of the PID control system that will fix this behavior for the face model. I'm going to close this and consolidate updates about the PID system in #48.
I'm truly amazed at all of the prototypes being developed from this quick tutorial! The original tutorial code has poor API surfaces for additional development though, so I'm rewriting this tool to be usable as a library. I want to make it dead-simple to generate a new prototype app, optionally bring your own model, and calibrate the control scheme.

Leigh,
Thank you much for input! I know my camera setup & orientation is exactly same with yours but about 3 to 8' distance.
I also suspect new Buster release may have something to do with this behavior (Your setup, I believe is started from pre-Buster 8-20-2020 release vs mine is Pi4 8GB with new Buster release)
I'll try with diffirent PID tinkering & hope that'll fix this behavior in my setup.
BTW; Your setup & servo movements are much smoother and predictably solid than Intels's NCS2 with OpenVINO + SSD model setup(Quite bit of jerks & sudden jolt of occasional movement--occasional jitter and PID setting always goes into oscillation eventually, no matter what value I change and still work in progress)
Your work is superior & solid!!!
LMK, if you want to try Pablo's FOC (Dual Brushless motor FOC controller for closed loop position control--I ordered 2 and I have 1 extra for you to experiment with and share with us if you like to, it's basically older version of 2 axe BGC32 controller board), I can also order 2 motor with encoder plus build a pan & tilt frame for you.
I believe, You can do bunch of cool control with it, dynamic PID setup, almost realtime tracking!


[IOS - Recursive call] Method "sendMessages" sends dozens of notifications

Hello,
I'm having trouble using this bundle in a production environment : some of my notifications are sent dozens of time to the same device.
I'm using $this->container->get('rms_push_notifications')->send($message); in a 50 loops foreach. Everything works fine until a notification is detected as failed. Then the method sendMessages() calls itself recursively to resend to resend the failed messages, but it sends again those that succeded as well.
Here is the recursive call I'm talking about : https://github.com/richsage/RMSPushNotificationsBundle/blob/master/Service/OS/AppleNotification.php#L146
Not sure if it is a misuse of the bundle, or an actual bug. Any help would be appreciated :)
Thank you

(This is timely: excuse my deconstructing the code "out loud". I started this trying to reassure myself that I'm not going to meet the same problem when I do something similar to you. But now, I've concluded that there is a bug here.)
It's a strange bit of code, and the reason for the recursion and the queue wasn't immediately obvious to me.
AppleNotification::send() is the only method that adds a message into the queue (the array $messages), but it also then immediately sends it with sendMessages().
If there's a failure, sendMessages() calls itself with (result['identifier'] + 1) to start at the "next" message in the queue. But how can there be a subsequent message in the queue when send() is the only method that can put one there, and is the only method (other than itself) that calls sendMessages()?
On first read-through, I thought it was adding one to the $lastMessageId when it calls itself, but it isn't. Not directly, anyway. It's taking the "Notification identifier" from Apple's server response, (which in turn is set by the sending party, i.e. this code), and adding 1 to that. As long as that value is actually increasing each time we should be fine...  and where is this value set? Well, that's being set via send()'s call to createPayload(), which is where we're incrementing $lastMessageId.
Obviously in your case (and mine!) there's the one instance of the Symfony service rms_push_notifications.ios instantiating the AppleNotification class, which send() is being invoked on over and over. So it is building up that queue as it goes, and I can't see any way in which that could reset within the same instance of AppleNotification (though, if you called it a lot, it could wrap) whilst the queue didn't.
I believe this weird construction is because Apple's replies to the message sending is asynchronous with the submission of the messages. The [Apple docs] (https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1) say "The binary interface is asynchronous". They also say "If you send a notification that is malformed or otherwise unintelligible, APNs returns an error-response packet and closes the connection. Any notifications that you sent after the malformed notification using the same connection are discarded, and must be resent".
So, I read this as saying that, if you keep sending messages at some point you may get back the error-response packet which tells you at which point your sending failed (and then closes down the TCP connection.)
When that happens, sendMessages() will commence sending from the subsequent message id to the one that failed, which is nice (although there's no way for the caller of send() to instantly know which one actually failed, and it's probably already moved onto the next one, it can get it - slightly inconveniently - via getResponses())
I think the bug is that it doesn't break out of the loop when the recursive call of sendMessages() returns. If there were multiple messages in the queue beyond the failed message then it could process them again (the recursive call) and then again on the return. Does that sound right? @richsage ?

@jamesrgrinter I've made the same code analyze for myself. I think you're right.
I've two question about your post :

Have you found a way to reproduce the bug ? I've try with 3 devices, the second has a wrong token. I've not encounter the issue.
Your solution would be to add break; right after the recusive call (or maybe after $errors[] = $result;). Does it work ?

I am also afraid that this bug append to me in a production environment. So I would like to find a way to correct it. But without reproducing the issue, it's difficult !

@jamesrgrinter apologies for the delay in coming back to this, and thanks for taking the time to write your detailed response :-) I believe your analysis is correct, although I've not had chance to investigate further yet.
@Sigmanet15 did you manage to reproduce the issue?
Ping @rjmunro - could you also take a look at this and see what you think?

@richsage sorry I've not reproduce this issue..

Is this corrected now ? I think I have the same problem...


How to register your account?

There is a way to login through Mson CLI but I don't see any way to register.

Hi @divyanshub024 👋
Thanks for opening an issue!
We’ll be doing a closed alpha shortly and you’ll have the ability to join the waitlist. Sorry for the inconvenience and thanks so much for expressing interest! 💙🧱

Hey @felangel 👋
Thanks for the info. I would love to try this Alpha version soon. And Best of luck for this Alpha launch. I think whole flutter community is excited about it. 💙
Happy Bricking... 🧱


What is 'path' => 'backups'?

Hey,
Nice package. I use 'path' => 'backups' and my backups are saved in storage/app directory. Will be an option to restore the backups in feature?

Version 2.3.1 fixes that bug. I'm not planning on adding restore functionality. See #23.


[docs-infra] Square drawer corners

Regarding https://m3.material.io/components/navigation-drawer/overview: Google Calendar has a round corner while Gmail has a square corner on my Android phone. Gmail feels much better. Gmail has x2 more users than Google Calendar according to https://play.google.com/store/apps/details?id=com.google.android.gm&hl=en&gl=US. So I feel like we could do the same for the docs.
Before

After

I noticed this in #37933.

With vertical drawers, a rounded corner feels a lot better, I think it's because when vertical, it covers the whole screen width.


Generic distance metric

Codecov Report

Merging #68 (44ba591) into next (e1489a7) will increase coverage by 0.49%.
The diff coverage is 94.54%.

:exclamation: Current head 44ba591 differs from pull request most recent head f609983. Consider uploading reports for the commit f609983 to get more accurate results

@@            Coverage Diff             @@
##             next      #68      +/-   ##
==========================================
+ Coverage   83.91%   84.40%   +0.49%
==========================================
  Files          29       29
  Lines        3593     3636      +43
==========================================
+ Hits         3015     3069      +54
+ Misses        578      567      -11

Impacted Files
Coverage Δ

src/fixed/query/nearest_n.rs
100.00% <ø> (ø)

src/fixed/query/within.rs
99.28% <ø> (-0.72%)
:arrow_down:

src/fixed/query/within_unsorted.rs
100.00% <ø> (ø)

src/float/query/nearest_n.rs
94.11% <ø> (ø)

src/float/query/within_unsorted.rs
94.30% <ø> (ø)

src/lib.rs
100.00% <ø> (ø)

src/nearest_neighbour.rs
46.15% <33.33%> (ø)

src/best_neighbour.rs
46.15% <46.15%> (ø)

src/common/generate_best_n_within.rs
100.00% <100.00%> (ø)

src/common/generate_nearest_n.rs
100.00% <100.00%> (ø)

... and 8 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Segmentation fault on launch.sh

Today i restarted my containter due to the last seasonal update, i encountered this error on restarting.
I tried to find more information about it, but i couldn't find any clues. Its seems to me that could be a display problem, because the segmentation error code changed when i used other docker images (trying to add /tmp/.X11-unix as a volume).
These are the docker logs before dying

2023-02-09T02:54:15.640856047Z
2023-02-09T02:54:17.548378709Z Connecting anonymously to Steam Public...OK
2023-02-09T02:54:17.548393416Z Waiting for client config...OK
2023-02-09T02:54:18.630622577Z Waiting for user info...OK
2023-02-09T02:54:18.630636554Z Success! App '1007' already up to date.
2023-02-09T02:54:18.630639437Z Success! App '1963720' already up to date.
2023-02-09T02:54:18.750413071Z Started server process with pid 70
2023-02-09T02:54:18.753308463Z [UnityMemory] Configuration Parameters - Can be set up in boot.config
2023-02-09T02:54:18.753324082Z     "memorysetup-bucket-allocator-granularity=16"
2023-02-09T02:54:18.753327246Z     "memorysetup-bucket-allocator-bucket-count=8"
2023-02-09T02:54:18.753329932Z     "memorysetup-bucket-allocator-block-size=4194304"
2023-02-09T02:54:18.753332455Z     "memorysetup-bucket-allocator-block-count=1"
2023-02-09T02:54:18.753334751Z     "memorysetup-main-allocator-block-size=16777216"
2023-02-09T02:54:18.753337108Z     "memorysetup-thread-allocator-block-size=16777216"
2023-02-09T02:54:18.753339438Z     "memorysetup-gfx-main-allocator-block-size=16777216"
2023-02-09T02:54:18.753341676Z     "memorysetup-gfx-thread-allocator-block-size=16777216"
2023-02-09T02:54:18.753344034Z     "memorysetup-cache-allocator-block-size=4194304"
2023-02-09T02:54:18.753346415Z     "memorysetup-typetree-allocator-block-size=2097152"
2023-02-09T02:54:18.753349073Z     "memorysetup-profiler-bucket-allocator-granularity=16"
2023-02-09T02:54:18.753351476Z     "memorysetup-profiler-bucket-allocator-bucket-count=8"
2023-02-09T02:54:18.753353706Z     "memorysetup-profiler-bucket-allocator-block-size=4194304"
2023-02-09T02:54:18.753355795Z     "memorysetup-profiler-bucket-allocator-block-count=1"
2023-02-09T02:54:18.753357968Z     "memorysetup-profiler-allocator-block-size=16777216"
2023-02-09T02:54:18.753360084Z     "memorysetup-profiler-editor-allocator-block-size=1048576"
2023-02-09T02:54:18.753362316Z     "memorysetup-temp-allocator-size-main=4194304"
2023-02-09T02:54:18.753364380Z     "memorysetup-job-temp-allocator-block-size=2097152"
2023-02-09T02:54:18.753366894Z     "memorysetup-job-temp-allocator-block-size-background=1048576"
2023-02-09T02:54:18.753369359Z     "memorysetup-job-temp-allocator-reduction-small-platforms=262144"
2023-02-09T02:54:18.753371810Z     "memorysetup-temp-allocator-size-background-worker=32768"
2023-02-09T02:54:18.753374213Z     "memorysetup-temp-allocator-size-job-worker=262144"
2023-02-09T02:54:18.753376569Z     "memorysetup-temp-allocator-size-preload-manager=262144"
2023-02-09T02:54:18.753378816Z     "memorysetup-temp-allocator-size-nav-mesh-worker=65536"
2023-02-09T02:54:18.753385945Z     "memorysetup-temp-allocator-size-audio-worker=65536"
2023-02-09T02:54:18.753389582Z     "memorysetup-temp-allocator-size-cloud-worker=32768"
2023-02-09T02:54:18.753391990Z     "memorysetup-temp-allocator-size-gfx=262144"
2023-02-09T02:54:19.052049163Z ./launch.sh: line 46:    70 Segmentation fault      (core dumped) DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../Steamworks SDK Redist/linux64/" ./CoreKeeperServer -batchmode -logfile -world "${WORLD_INDEX}" -worldname "${WORLD_NAME}" -worldseed "${WORLD_SEED}" -gameid "${GAME_ID}" -datapath "${STEAMAPPDATADIR}" -maxplayers "${MAX_PLAYERS}" -logfile CoreKeeperServerLog.txt

Extra info: The server where the container is running is also running other stuff but hasn't been updated in a long time.

I just experienced this same issue.
I wanted to play the new valentines update, and restarted the container to force an update.
When it attempted to start, this is the error I see in the logs:
Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK Success! App '1007' already up to date. Success! App '1963720' already up to date. Started server process with pid 69 [UnityMemory] Configuration Parameters - Can be set up in boot.config     "memorysetup-bucket-allocator-granularity=16"     "memorysetup-bucket-allocator-bucket-count=8"     "memorysetup-bucket-allocator-block-size=4194304"     "memorysetup-bucket-allocator-block-count=1"     "memorysetup-main-allocator-block-size=16777216"     "memorysetup-thread-allocator-block-size=16777216"     "memorysetup-gfx-main-allocator-block-size=16777216"     "memorysetup-gfx-thread-allocator-block-size=16777216"     "memorysetup-cache-allocator-block-size=4194304"     "memorysetup-typetree-allocator-block-size=2097152"     "memorysetup-profiler-bucket-allocator-granularity=16"     "memorysetup-profiler-bucket-allocator-bucket-count=8"     "memorysetup-profiler-bucket-allocator-block-size=4194304"     "memorysetup-profiler-bucket-allocator-block-count=1"     "memorysetup-profiler-allocator-block-size=16777216"     "memorysetup-profiler-editor-allocator-block-size=1048576"     "memorysetup-temp-allocator-size-main=4194304"     "memorysetup-job-temp-allocator-block-size=2097152"     "memorysetup-job-temp-allocator-block-size-background=1048576"     "memorysetup-job-temp-allocator-reduction-small-platforms=262144"     "memorysetup-temp-allocator-size-background-worker=32768"     "memorysetup-temp-allocator-size-job-worker=262144"     "memorysetup-temp-allocator-size-preload-manager=262144"     "memorysetup-temp-allocator-size-nav-mesh-worker=65536"     "memorysetup-temp-allocator-size-audio-worker=65536"     "memorysetup-temp-allocator-size-cloud-worker=32768"     "memorysetup-temp-allocator-size-gfx=262144" ./launch.sh: line 46:    69 Segmentation fault      (core dumped) DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../Steamworks SDK Redist/linux64/" ./CoreKeeperServer -batchmode -logfile -world "${WORLD_INDEX}" -worldname "${WORLD_NAME}" -worldseed "${WORLD_SEED}" -gameid "${GAME_ID}" -datapath "${STEAMAPPDATADIR}" -maxplayers "${MAX_PLAYERS}" -logfile CoreKeeperServerLog.txt

Just confirming that I'm seeing the same thing.

I think this is related to the game server itself: https://steamcommunity.com/app/1621690/discussions/0/3759978783504303058/

You are right. Im closing the issue.
Thanks!


Investigate port usage within WMCore services

Impact of the new feature
WMCore web-services
Is your feature request related to a problem? Please describe.
This goes along the migration away from x509 grid certificates, with the adoption of tokens.
Describe the solution you'd like
Look at the gitlab report provided by Valentin and evaluate the port usage from our WMCore services, both WMAgent and CMSWEB-based services as well. Here is a gitlab with that information:
https://gitlab.cern.ch/cms-http-group/doc/-/issues/237
Further info in this HN thread: https://hypernews.cern.ch/HyperNews/CMS/get/webInterfaces/1752.html
Describe alternatives you've considered
none
Additional context
Reports should be made in the gitlab ticket, not here!

@todor-ivanov this is one of the issues that Valentin is waiting for our feedback. If you prefer to work on https://github.com/dmwm/WMCore/issues/10118 instead, let me know and we can swap. Anything works for me.

Here is what I find after applying few filters over the cmsweb access logs for December 2020, which might be considered as coming from WMcore/WMAgent and requesting port 443:
| # Req: | API:                                  | DN:                                                                                | Client:                         | Port: |
|--------+---------------------------------------+----------------------------------------------------------------------------------------------------------+---------------------------------+-------|
|    140 | /couchdb/acdcserver/...               | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|   1189 | /couchdb/acdcserver/...               | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|    796 | /couchdb/_all_dbs /...                | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|    399 | /couchdb/_all_dbs /...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|    784 | /couchdb/_all_dbs /...                | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|    170 | /couchdb/reqmgr_config_cache/...      | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|    315 | /couchdb/reqmgr_config_cache/...      | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|  15260 | /couchdb/reqmgr_workload_cache/...    | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|  36657 | /couchdb/reqmgr_workload_cache/...    | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  30191 | /couchdb/reqmgr_workload_cache/...    | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|   1559 | /couchdb/t0_request/...               | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|    442 | /couchdb/tier0_wmstats/...            | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|   1298 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|  43038 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "CouchDB/1.6.1"                 |   443 |
|   4658 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  14186 | /couchdb/wmstats/...                  | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "CouchDB/1.6.1"                 |   443 |
|   4095 | /couchdb/wmstats/...                  | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|   4286 | /couchdb/wmstats_logdb/...            | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|  42319 | /couchdb/wmstats_logdb/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  35829 | /couchdb/wmstats_logdb/...            | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|  36295 | /couchdb/workloadsummary/...          | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  28800 | /couchdb/workloadsummary/...          | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
| 118193 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|   8452 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "CouchDB/1.6.1"                 |   443 |
|  91118 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  29899 | /couchdb/workqueue/...                | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "CouchDB/1.6.1"                 |   443 |
|  23897 | /couchdb/workqueue/...                | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|  58888 | /couchdb/workqueue_inbox/...          | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | "WMCore.Services.Requests/v002" |   443 |
|  89422 | /couchdb/workqueue_inbox/...          | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0280.cern.ch                                                 | "WMCore.Services.Requests/v002" |   443 |
|  21239 | /couchdb/workqueue_inbox/...          | /DC=org/DC=incommon/C=US/ST=Illinois/L=Batavia/O=Fermi Research Alliance/OU=Fermilab/CN=wmagent.fnal.gov | "WMCore.Services.Requests/v002" |   443 |
|     15 | /dbs/prod/global/DBSReader/blocks     | /DC=ch/DC=cern/OU=computers/CN=dmwm/cmsweb.cern.ch                                                       | zlib/1.2.8"                     |   443 |
|     40 | /dbs/prod/global/DBSReader//filelumis | /DC=ch/DC=cern/OU=computers/CN=wmagent/vocms0192.cern.ch                                                 | zlib/1.2.8"                     |   443 |
|--------+---------------------------------------+----------------------------------------------------------------------------------------------------------+---------------------------------+-------|

Hi @amaltaro please please take a quick look, and just tell me if the way the information is represented above is adequate enough so we can forward the message to http group in the gitlab ticket?

After enforcing the change from the following PR [1] to take effect in both my private central services instance and my agent  I ended up with only few calls to port 433 through the frontend which are targeting my central instance. They are all originating from two clinets WMCore.Services.Requests/v002 and CouchDB/1.6.1 and the sources are basically from the central services themselves calling a small set of APIs and the calls from the agent calling the exact same set of APIs. Everything else is going through port 8443. Here is the table view of the above [2]
[1]
https://github.com/dmwm/WMCore/pull/8726
[2]
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
| # Req: | API:                                          | DN:                                        | Client:                         | ClientAddr:            | Port: |
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
|      1 | /couchdb/_all_dbs /...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|     60 | /couchdb/reqmgr_workload_cache/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|      6 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |   443 |
|     23 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|    504 | /couchdb/wmstats_logdb/...                    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|     44 | /couchdb/workloadsummary/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|     23 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |   443 |
|     30 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |   443 |
|      1 | /couchdb/_all_dbs /...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|      1 | /couchdb/acdcserver/...                       | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|    135 | /couchdb/reqmgr_auxiliary/...                 | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|   3905 | /couchdb/reqmgr_workload_cache/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|     28 | /couchdb/t0_request/...                       | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|     55 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|    217 | /couchdb/wmstats_logdb/...                    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|     74 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|      8 | /couchdb/workqueue_inbox/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |   443 |
|        |                                               |                                            |                                 |                        |       |
|        |                                               |                                            |                                 |                        |       |
|   1691 | /reqmgr2/data/request                         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     49 | /reqmgr2/data/wmagentconfig/vocms0290.cern.ch | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     18 | /wmstatsserver/data/filtered_requests         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     11 | /reqmgr2/data/campaignconfig/ALL_DOCS         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /reqmgr2/data/cmsswversions                   | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     65 | /reqmgr2/data/request                         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      5 | /reqmgr2/data/transferinfo/ALL_DOCS           | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      8 | /reqmgr2/data/unifiedconfig/config            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      4 | /wmstatsserver/data/filtered_requests         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /wmstatsserver/data/globallocks               | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+

The reason is now well known. It is because in some places and in CouchDB Service for sure we import Requests and JSONRequests classes directly but not through the WMCore.Services.Service class:
from WMCore.Services.Requests import JSONRequests

So after applying the following patch [1] (on both central services and wmagent) I was able to forward every query from WMCore.Services.Requests/v002 to port 8443. Here is the outcome: [2]. Except the two comming directly from the couchDB client, which I hope is configurable.
Few things need to be mentioned though:

I do not like the idea of patching things every time I deploy a private instance just because my hostname is not hardcoded for  port forwarding as the one of https://cmsweb... is. But once I loosened the constrained to just https://... Reqmgr broke because we are actually trying to connect to one non-cmsweb url which does not have port 8443 open, and this one is: https://cmssdt.cern.ch
The patch I applied is affecting only the toplevel class Requests from which JSONRequests inherits, which is a valid cource of action provided that JSONRequests follow the standard for instantiating the parent class, which it does NOT. What I mean is that JSONRequests does not use
super().__init__()
in order for it to be done but it is calling the parent class constructor directly:
  Requests.__init__(self, url, idict)
Which is about to break the MRO (MethodResolutionOrder) when it comes to second level of inheritance with dependent classes. So I would opt for fixing that, but I am not sure if this is intentional or not.

[1]
$ git diff --no-color src/python/WMCore/Services/Requests.py
diff --git a/src/python/WMCore/Services/Requests.py b/src/python/WMCore/Services/Requests.py
index 7356fd9..f78e3a4 100644
--- a/src/python/WMCore/Services/Requests.py
+++ b/src/python/WMCore/Services/Requests.py
@@ -79,6 +79,11 @@ class Requests(dict):
         if self.pycurl:
             self.reqmgr = RequestHandler()

+        # setup port 8443 for cmsweb services
+        if url.startswith("https://cmsweb") \
+           or url.startswith("https://tivanov"):
+            url = url.replace('.cern.ch/', '.cern.ch:8443/', 1)
+
         # set up defaults
         self.setdefault("accept_type", 'text/html')
         self.setdefault("content_type", 'application/x-www-form-urlencoded')

[2]
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
| # Req: | API:                                          | DN:                                        | Client:                         | ClientAddr:            | Port: |
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
|      6 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |   443 |
|     19 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |   443 |
|        |                                               |                                            |                                 |                        |       |
|        |                                               |                                            |                                 |                        |       |
|      1 | /couchdb/_all_dbs /...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     27 | /couchdb/reqmgr_workload_cache/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      6 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     67 | /couchdb/wmstats_logdb/...                    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     22 | /couchdb/workloadsummary/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      3 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|    231 | /reqmgr2/data/request                         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      9 | /reqmgr2/data/wmagentconfig/vocms0290.cern.ch | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      2 | /wmstatsserver/data/filtered_requests         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      1 | /couchdb/_all_dbs /...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /couchdb/acdcserver/...                       | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     29 | /couchdb/reqmgr_auxiliary/...                 | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|    522 | /couchdb/reqmgr_workload_cache/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      7 | /couchdb/t0_request/...                       | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     13 | /couchdb/wmstats/...                          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     64 | /couchdb/wmstats_logdb/...                    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     21 | /couchdb/workqueue/...                        | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      2 | /couchdb/workqueue_inbox/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      4 | /reqmgr2/data/campaignconfig/ALL_DOCS         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /reqmgr2/data/cmsswversions                   | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|     17 | /reqmgr2/data/request                         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      2 | /reqmgr2/data/transferinfo/ALL_DOCS           | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      4 | /reqmgr2/data/unifiedconfig/config            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /wmstatsserver/data/filtered_requests         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
|      1 | /wmstatsserver/data/globallocks               | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tivanov-unit02.cern.ch |  8443 |
+--------+-----------------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+

After the configuration change which @amaltaro suggested in the PR we have managed to forward also the CouchDB/1.6.1 client to port 8443. [1]
[1]
 +--------+---------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
| # Req: | API:                                  | DN:                                        | Client:                         | ClientAddr:            | Port: |
+--------+---------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+
|      1 | /wmstatsserver/data/teams             | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | zlib/1.2.8"                     | tiavnov-unit02.cern.ch |   443 |
|        |                                       |                                            |                                 |                        |       |
|        |                                       |                                            |                                 |                        |       |
|     23 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |  8443 |
|    491 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "CouchDB/1.6.1"                 | vocms0290.cern.ch      |  8443 |
|      3 | /couchdb/_all_dbs /...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      2 | /couchdb/acdcserver/...               | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     78 | /couchdb/reqmgr_workload_cache/...    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|    102 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|   2418 | /couchdb/wmstats_logdb/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|      4 | /couchdb/workloadsummary/...          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|    227 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     71 | /couchdb/workqueue_inbox/...          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|   1222 | /reqmgr2/data/...                     | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     86 | /wmstatsserver/data/filtered_requests | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | vocms0290.cern.ch      |  8443 |
|     80 | /couchdb/_all_dbs /...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|      1 | /couchdb/acdcserver/...               | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    866 | /couchdb/reqmgr_auxiliary/...         | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|  10120 | /couchdb/reqmgr_workload_cache/...    | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    105 | /couchdb/t0_request/...               | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    244 | /couchdb/wmstats/...                  | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    794 | /couchdb/wmstats_logdb/...            | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    736 | /couchdb/workqueue/...                | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    448 | /couchdb/workqueue_inbox/...          | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|    474 | /reqmgr2/data/...                     | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|     15 | /wmstatsserver/data/filtered_requests | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|      1 | /wmstatsserver/data/globallocks       | /DC=ch/DC=cern/OU=computers/CN=wmagent/... | "WMCore.Services.Requests/v002" | tiavnov-unit02.cern.ch |  8443 |
|     66 | /reqmgr2/data/...                     | /DC=ch/DC=cern/OU=Organic Units/OU=Users/. | "-"                             | tiavnov-unit02.cern.ch |  8443 |
+--------+---------------------------------------+--------------------------------------------+---------------------------------+------------------------+-------+


Out-dated error message in weave script

It says "use the -iprange option on 'weave launch' to enable IP address allocation".
a. the option is now called -ipalloc-range
b. the default is flipped now - it's on by default

Fixed in 5635ba1


Support UWP (and .NET Native)

This uses the NuGet 3 runtimes directory to get the native library into the app. This will require a NuGet 3 client to install the package.
There are currently some bugs around CLR AnyCPU projects that prevent the package from being installed. I'll work with the NuGet team on these.

:shipit:


DS4Windows and Teamspeak 3 64x Mismatch at Windows 7

Description: Whenever a DS4 controller is connected with the "Hide the DS4 Controller" option activated while Teamspeak is already open, I encounter the following message.
Could not open DS4 (MAC Address) exclusively. You must quit other applications like Steam, UPlay before activating "Hide DS4 Controller" option.
If you connect the controller and hide the DS4 controller sucessfuly and then shortly after open the Teamspeak 3, the computer will freeze until you disconnect the controller, or somehow manage to close the Teamspeak process.
Steps to reproduce are simple.
If you open DS4Windows and try to Hide DS4 Controller with teamspeak open to get the error or try to open teamspeak with the DS4 controller already hidden by DS4Windows to freeze your computer, one of the two.
Other Information:
Teamspeak 3 - 64bit Edition - Version <IP_ADDRESS>
DS4Windows - 1.4.27
Log:

I also am encountering this error. I couldn't for the life of me figure out why the Exclusive option wouldn't work.

I am getting this too. The log doesn't show anything though, loading TS3 with the controller connected causes my whole computer to hang.

I just found a way to work around this in TS3: Go to Settings, then Options then Hotkeys and at the bottom right there's a drop down list that normally says "Default", change it to the "Keyboard & Mouse Only" setting. Worked for me.

Omg!  I had noticed that TS3 logs the controllers connection in its log and assumed it was monitoring it to see if it could use it for hotkeys but hadn't had a chance to look around for where a setting might be to change.


In model_zool models, what does these codes and numbers mean?

For better understanding this question, let take the person-vehicle-bike-detection-crossroad as an example:
In the below code, what is the meaning of the suffix number?
person-vehicle-bike-detection-crossroad-0078
person-vehicle-bike-detection-crossroad-1016

Now let's go inside the person-vehicle-bike-detection-crossroad-0078 folder.
FP16
FP32-INT8
FP32

Now, what is the meaning of these three suffixes for each folder?
Why this question is important?
Answer: Because for better user experience, I want to know the usage cases of these differences between the same model, and take the best type of the model to satisfy the requirements. For example, if I don't know the meaning of these suffixes, then I could not select the one which I am looking for, so the result will be not good, and the user experience will decrease.
Note: I search for these question but did not find any good documentation to answer me this question, so came here and asked about these questions, maybe helpful for other people who have the same question.
Thanks in advance!!

Hi @Bahramudin
I believe it's the name of the model and version, for example person-vehicle-bike-detection-crossroad is the name and 0078 or 1016 is the version.
The next sub-folders is the same model as different model precisions, FP16, FP32, INT8. Some devices only support a certain model precision. Take a look at the following table
Regards,
Jesus

Hmm, thanks for the reply! About the versions, I want to ask that what mechanism is used for versioning the model for example as normal we have the versions like this:
0.1, 0.2, 1.0, 2.5, etc... so there is it means the higher the newer, but what about these models are they the same with normal versions? E.g: 1016 is newer than 0078, am I right?
One more thing, how we know what changes came with the new version, especially improved accuracy or speed, and how much did it improve?
Thanks!!

@Bahramudin have you had a chance to look and compare model descriptions to find what is the difference?
person-vehicle-bike-detection-crossroad-0078
person-vehicle-bike-detection-crossroad-1016

@vladimir-dudnik Not I got some resources to compare these models and the using cases.
Thanks a lot!!


[BUG]: KryptonForm crashing Visual Studio

Hi
Is anyone else experiencing crashes when attempting to switch to design mode when using KryptonForm?

Yep. I am. I updated to 5.500.2002 tonight and I have the same issue.
Not only that, but when I run my application, I get a stackoverflowexception on the constructor of my form:

This never happened with Krypton v472.  Could these two issues be related?

I just attached another instance of VS to my instance with the krypton form in it and as soon as I opened the form in the IDE I got a stackoverflowexception.

So it seems like it's all related.

OK, I figured it out.
In your constructor for KryptonForm you have this:
if (!GetIsInAdministratorMode())

And the method has this:
        /// <summary>Gets the is in administrator mode.</summary>
        /// <returns>IsInAdministratorMode</returns>
        public static bool GetIsInAdministratorMode()
        {
            KryptonForm form = new KryptonForm();

            return form.IsInAdministratorMode;
        }

As you can see, you're calling the GetIsInAdministratorMode in the ctor, and in the method, it's calling the ctor, which is calling GetIsInAdministratorMode, which is calling the ctor...
You get the idea.

Weird, because that code didn't change between 5.4xx and 5.500... unless there are issues with netcoreapp3.1? Does this always return true?

I think this code was added on 726603a7f8d09082386fd8e2ffaa69c0999e653a and 6083f783c31675000e858245a0e49ad624187c08 when trying to fix #17

I don't understand what these changes were supposed to fix.
Creating a new KryptonForm inside a method (and never disposing it) will cause memory leaks. And setting an instance property value will never change anything.
I suggest we rollback these changes then review the original #17 issue and rewrite a new fix.

I found the original commit which introduced this change: https://github.com/Wagnerp/Krypton-NET-5.470/commit/4121e8c4
I see several problems with this code.
IsInAdministratorMode should be static/get only (no reason it's different between two instances) if it's supposed to detect if the user is in admin mode.
I suppose this commit was added to append automatically a suffix to the window title when the user is an administrator.
If you want to allow the developer to hide this suffix, IsInAdministratorMode should be kept readonly and a new property (for example AppendAdministratorText) which could be defaulted to true or false (depending if you want to change the previous behavior by default) could be responsible to append the text or not.
For now, I will revert the changes which cause the SO exception, then we will discuss this changes in #17.

Ahh got it... I think
   if (!GetIsInAdministratorMode())
   {
        // Hide window
        Hide();
    }
    else
    {
        Show();
    }

Needs to alter the window text, not show/hide the window!
Schoolboy error!

I'll let you handle that

New code, though { may cause issues
   if (GetIsInAdministratorMode())
            {
                // Create a temporary variable to hold window text
                string tempText = Text;

                switch (BracketType)
                {
                    case BracketType.CURVEDBRACKET:
                        Text = $"({ tempText })";
                        break;
                    case BracketType.CURLYBRACKET:
                        Text = $"{{ tempText }}";
                        break;
                    case BracketType.SQUAREBRACKET:
                        Text = $"[{ tempText }]";
                        break;
                    case BracketType.NOBRACKET:
                        Text = $"{ tempText }";
                        break;
                    default:
                        break;
                }
            }
            else
            {
                Text = Text;
            }

And I'll take the previous comment by @tbolon into account

Hold on...
I forgot that I wrote this ages ago!!!
    /// <summary>
        /// Updates the title.
        /// </summary>
        /// <param name="hasAdministrativeRights">if set to <c>true</c> [has administrative rights].</param>
        /// <param name="bracketType">The type of bracket that will encapsulate the administrator text.</param>
        public void UpdateTitle(bool hasAdministrativeRights, BracketType bracketType = BracketType.CURVEDBRACKET)
        {
            if (hasAdministrativeRights)
            {
                switch (bracketType)
                {
                    case BracketType.CURVEDBRACKET:
                        Text = $@"{ Text } - ({ AdministratorText })";
                        break;
                    case BracketType.CURLYBRACKET:
                        Text = $@"{ Text } - {{{ AdministratorText}}}";
                        break;
                    case BracketType.SQUAREBRACKET:
                        Text = $@"{ Text } - [{ AdministratorText }]";
                        break;
                    case BracketType.NOBRACKET:
                        Text = $@"{ Text } - { AdministratorText }";
                        break;
                    default:
                        break;
                }
            }
        }

This should simplify it UpdateTitle(AppendAdministratorText, BracketType);!!!

@tbolon & @Smurf-IV  I think that I've misunderstood #17, which needs more discussion. A discussion needs to be held in regards to what happens if elevation is required, but we're still running as a normal user?

You guys have any ETA on when the nuget packages will be updated?

@tbolon & @Smurf-IV I think that I've misunderstood #17, which needs more discussion. A discussion needs to be held in regards to what happens if elevation is required, but we're still running as a normal user?

If the App requires elevation, then let the app sort it out; as in #17, It was displaying a message box asking the user to run in elavated mode.

@Smurf-IV Yes I took the if statement out & reverted the code to before that change, but it still requires testing. Plus I'm leaving the developer decide on what to do, as per @tbolon comment about this.
@Tape-Worm I can't give you an ETA yet, as I need to fix my build environment, plus need to test the fixes.

I don't think its the administrator code causing the issue, I have a feeling it's something else or .NET 3.5.


Add /me endpoint

In some cases it is useful to know if the auth token is valid or not.
All other immutable endpoints provide full information even without an auth token.
Only fetching specific book of specific user does not work unauthorized, but this endpoint may be different depending if the book exist or not.
Added simple /me entrypoint that prints logged-in user info.

@erev0s FYI

hi @alexkutsan, thank you for your patience. This has been merged.


DDMM decimal seconds do not get recognized

I have a batch of coordinates expressed as eg 43° 51' 45.12345" N, 120° 51' 19.333" W. Unfortunately, the decimal seconds result in failed parsing and GeoPoint.new returns nil for lat and lng.

You are most welcome to patch the parsing code and submit a PR. Haven't worked on this project for years... Hope it works out for you ;)


Service did not respond to the start or control request in a timely manner

I'm occasionally seeing this error (like once every 20-30 service starts):
"Failed to start service. The service did not respond to the start or control request in a timely manner."
The code I am using is as follows:
package main

import (
	"flag"
	"fmt"
	"log"
	"time"

	"github.com/kardianos/service"
)

var (
	logger  service.Logger
	svcFlag = flag.String("service", "", "Control the system service.")
)

// Program structures.
//  Define Start and Stop methods.
type program struct {
}

func (p *program) Start(s service.Service) error {
	if service.Interactive() {
		logger.Info("Running in terminal.")
	} else {
		logger.Info("Running under service manager.")
	}

	// Start should not block. Do the actual work async.
	mainClient := asclient.NewASClient(false)
	diagClient := asclient.NewASClient(true)

	go p.run(mainClient)
	go p.run(diagClient)

	return nil
}

func (p *program) run(client *asclient.ASClient) error {
	logger.Infof("Service is running %v.", service.Platform())
	// From linux Mainloop:
	var err error
	var result *control.Result
	var asyncResult *control.Result
	var newCmd *control.Command

	asyncResultChan := make(chan *control.Result)

	// start async chan consumer
	go func() {
		for {
			res := <-asyncResultChan
			client.SaveResult(res, true)
		}
	}()

	logger.Info("Agent Starting")
	for {
		// Perform work.
		logger.Info("Do something.")
		time.Sleep(time.Minute)
		continue
	}
	return err
}

func (p *program) Stop(s service.Service) error {
	// Any work in Stop should be quick, usually a few seconds at most.
	logger.Info("Service shutting down.")
	log.Println("Service shutting down.")
	return nil
}

// Service setup.
//   Define service config.
//   Create the service.
//   Setup the logger.
//   Handle service controls (optional).
//   Run the service.
func mainLoop() {

	log.Println("Starting mainLoop")

	svcConfig := &service.Config{
		Name:        "asclient",
		DisplayName: "Asclient",
		Description: "Test asclient service",
	}

	prg := &program{}
	s, err := service.New(prg, svcConfig)
	if err != nil {
		log.Fatal(err)
	}
	errs := make(chan error, 5)
	logger, err = s.Logger(errs)
	if err != nil {
		log.Fatal(err)
	}

	go func() {
		log.Println("Starting log consumer")
		for {
			err, ok := <-errs
			if !ok {
				return
			}
			if err != nil {
				logger.Error(err)
			}
		}
		log.Println("Exiting log consumer")
	}()

	if len(*svcFlag) != 0 {
		err := service.Control(s, *svcFlag)
		if err != nil {
			fmt.Printf("Error: %q\n", err)
			fmt.Printf("Valid service actions: %q\n", service.ControlAction)
			log.Fatalf("Error: %q\n", err)
		}

		return
	}

	err = s.Run()
	if err != nil {
		logger.Error(err)
	}
}

That looks reasonable. I would add in the loges to see how quick it enters main() to when the Program.Start finishes. Maybe set a package variable var start = time.Now() and then subtract that in the Program.Start routine. Maybe something else is blocking.

In my systems, I have main(), which loads a config file from disk (super quick, no processing), then I do program.Start. In Start I may start a listener depending on the service. So I usually design my services to start in probably less then 10 ms. So just put work later maybe? I may be mis-understanding you though.

What you recommend is along the lines of what I was thinking, but was curious if there was some trick to letting SCM know sooner that the service is up and running so as not to kill it.  But I suppose a code restructure might work as well.

I'd really appreciate any help with this.

Here is what I would recommend: in run, put in a deferred recover:
func (p *program) run() {
	defer func() {
		if v := recover(); v != nil {
			logger.Error("panic in run", v)
		}
	}()
	db.Init()
	handlers.RunHTTP()
}

I suspect that it is starting, then crashing, and then not responding.

Thanks Daniel, I'll try that.

Any update on this, I have the same issue that starting a http server in run does not respond in time to a control request from Windows services.

Return from the start method ASAP, and if that isn't enough, delay real work started in a goroutines for a second.


fixing diff in core text

Good, I understand now why my other PR was not passing. The current master does not pass the tests...

Thanks for the fix!


[CI] What about migrating to GitHub actions?

as mentioned in https://github.com/ocaml-sf/learn-ocaml/pull/356#issuecomment-651216508, some recent issues w.r.t. the PR status feedback from Travis → GitHub, and the stability of the macOS build on Travis CI make me wonder whether it'd be useful to switch learn-ocaml's CI to GitHub Actions.
@yurug do you have an opinion on that?
AFAICT, the features provided by GitHub Actions are quite nice, and maybe the current test scripts could probably be reused with very few changes(?) − If need be I could have a look to prepare a PR, but not this week unfortunately :-/

That is something I was actually thinking about too. If you think you can prepare a PR to that end, that would be great!

OK @yurug, thanks for your reply! I'll prepare a PR then

@yurug the configuration I prepared is almost ready; I'll open the PR on this Wednesday.


XCPM doesn't work in Sonoma

XCPM doesn't work in Sonoma but it works in Ventura
machdep.xcpm.mode: 0

I don't use XCPM. My EFI folder and instructions are for re-enabling Legacy power Management


table view viz doesn't use time grain with Sqlalchemy table

Hi,
I want to create table view where counts are grouped by day.
I'm setting time grain to day but this has no effect.
I'm connecting to MySQL table.
Caravel version 0.11.0

Only time related visualization are affected by the time settings: table view is not one of them.

Said that on my pre 0.11 installation i can't use the time column as group by clause. @maver1ck do you see the same on 0.11?

@xrmx
I don't agree with you.
When I'm using druid I can use Time Granularity.

So you agree with me with something is broken :)

Yep.
Thanks for "bug" label.

We are using superset 0.13.2 with druid datasource, setting up a table viz with one day granularity since 7 days ago, but the actual query is with granularity: all, so no time column in the result table, is this a feature or a bug?
Thanks.

I think it's a new bug.

I have make a merge request,https://github.com/airbnb/superset/pull/1809

Notice: this issue has been closed because it has been inactive for 499 days. Feel free to comment and request for this issue to be reopened.


Adding "Real-IP" of causing request to metrics

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
Would be awesome to see the clients real ip in the metrics of traefik. With this certain security alert mitigations could be made, as you could configure alerts based on the request source ip.
Not sure which metrics would be affected, maybe we need new ones

Hi @hypery2k , could you provide more details ? What kind of metrics, etc...

I think none of the existing metrics works for this. But maybe use traefik_backend_requests_total as base and make metric for each request with the client_ip or make a new metric with name traefik_backend_requests_per_client_total which has the same structure as traefik_backend_requests_total but only for one client (source ip)

Hi @hypery2k , to help us  to understand better your request, could you elaborate by describing your use case in details with example please? Are you referring about the  metrics exposed trhough the API ? Or the Traefik's WebUI?
We also would want to know what is the Load Balancer used in front of Traefik, as the existence of the "Real-IP" attribute depends on this Loadbalancer (which tend to strip it off)?

Hi Damien,
nice to hear from you (last speaking at vilnius conference ;) ). Sure I can explain my use case:
I want to have metrics for all requests to see possible attackers which are trying to penetrate my API exposed via Traefik. So I want to see if IP 1 is making 1 request, where IP 2 creates maybe 1000 requests.
I'm using HAproxy within OpenShift, but we have other software were we already seeing the external IP, so now issue there.
I mean the metrics via the API.

Unfortunately this is difficult because an IP can have a lot of different values (2^32) and adding label based on a value with a high number of possible values (high cardinality) is not recommended by Prometheus, as explained here.
Also alerting per IP does not protect you from distributed attacks, which are a thing.
WDYT of using log collection and aggregation in order find out the potential IPs of attackers, and only alert on a high rate of requests ?
This way you know when your system is under a potential attack (high rate) and have the tools to find out where does the traffic comes from (log analysis and aggregate manually per RealIP).

mmmh really get your point. We don't expect that amount of requests, but maybe it would be better to check for metrics generally in haproxy for alerting or stick to log collection as proposed by you


Missing getScreenModel with voyager-koin

I have a Kotlin Multiplatform project with Voyager dependencies in commonMain like so:
implementation("cafe.adriel.voyager:voyager-bottom-sheet-navigator:" + extra["voyager.version"] as String)
implementation("cafe.adriel.voyager:voyager-koin:" + extra["voyager.version"] as String)

Screen Model is listed in a Koin module:
val commonModule = module {
    single<LibraryRepo> { LibraryRepoImpl(bandcampApi = get()) }
    factory { LibraryModel(libraryRepo = get()) }
}

Model:
class LibraryModel(private val libraryRepo: LibraryRepo) : StateScreenModel<LibraryState>(LibraryState()) {
}

Screen:
object LibraryScreen : Screen {
    @Composable
    override fun Content() {
        val libraryModel: LibraryModel = getScreenModel()
    }
}

However getScreenModel() is marked as an unresolved reference.

The Koin module currently only supports android due to previous versions of Koin not supporting Compose for Desktop, there is a PR to include other platforms now that koin supports it here #159.

Thank you for the prompt response. I'll mark this as closed.


[Needs Review] B07902085 張琪

A Pull Request (PR) should explain why we need this PR and how you implement it, so others could understand it quickly.
Since this is just a homework, you do not need to explain why and how.
Do NOT change the status to NeedsReview if you do not want to be graded yet.
Please fill in the following questions as feedback. It is totally optional and would not be graded.
What is the most challenging part in this homework?
Is this homework helpful for you?
Is there any suggestion?

PR readiness check list

[  ] Did it pass the Flake8 check?
[  ] Did you test this PR?
[  ] Did you change the title of this PR to the correct format ([status] student_ID)?

@amjltc295 I've revised my commit message. Is it okay now? Thank you.


Always allow superuser to login.

A superuser should always be able to login.
humanize.naturaldelta() returns "a day" for a negative timedelta, i.e. an expired password. Change the warning message accordingly. This helps users who are logged in at the time their password expires and superusers who login with an expired password.

Thanks, @hansonec for the PR. I have a client who has multiple superusers and wants their passwords to expire so I'll need to add this as a setting.

PR #4 is better. :-)


fedora packages doesn't work anymore

Describe the bug
I'm unable to succeed in any provided installation method:

curl/dnf:

Detected operating system as fedora/37.
Checking for curl...
Detected curl...
Downloading repository file: https://packagecloud.io/install/repositories/danstiner/softu2f/config_file.repo?os=fedora&dist=37&source=script
curl: (22) The requested URL returned error: 404

Unable to download repo config from: https://packagecloud.io/install/repositories/danstiner/softu2f/config_file.repo?os=fedora&dist=37&source=script

This usually happens if your operating system is not supported by
packagecloud.io, or this script's OS detection failed.

You can override the OS detection by setting os= and dist= prior to running this script.
You can find a list of supported OSes and distributions on our website: https://packagecloud.io/docs#os_distro_version

For example, to force CentOS 6: os=el dist=6 ./script.sh

If you are running a supported OS, please email<EMAIL_ADDRESS>and report this.

I've also tried to enforce older fedora (36) since 37 is a bit new and could be unsupported yet, but now, DNF complained that there is no package named softu2f

I've tried to run ./package.sh. it has built several RPMs but dnf didn't manage to install any of them (these from x86_64/ complained about "nothing provides softu2f-system-daemon-selinux needed by softu2f-system-daemon-0.4.2-1.fc36.x86_64")
I've some problems with cargo-built binaries (probably I haven't set them up correctly) but I'd really like to use rpms...

I was still on Fedora 35 so I just hadn't build new packages yet, this is a good reminder for me to upgrade haha
New packages for 36 are published to packagecloud.io. I couldn't do 37 yet as packagecloud hasn't added the option yet, they should soon.
Had to tweak the openssl dependency to get it building: https://github.com/danstiner/rust-u2f/tree/release-v0.4.2

Thank you!
So i should be able to install fc36 version on my fedora now?

Now I'm getting the following dnf error:
[~ (0) ]$ sudo dnf install softu2f.noarch
danstiner_softu2f                           767  B/s | 1.8 kB     00:02
Dependencies resolved.
============================================================================
 Package                       Arch   Version       Repository         Size
============================================================================
Installing:
 softu2f                       noarch 0.4.2-1.fc36  danstiner_softu2f 6.1 k
Installing dependencies:
 softu2f-system-daemon         x86_64 0.4.2-1.fc36  danstiner_softu2f 378 k
 softu2f-system-daemon-selinux noarch 0.1.0-1.fc36  danstiner_softu2f  20 k
 softu2f-user-daemon           x86_64 0.4.2-1.fc36  danstiner_softu2f 644 k

Transaction Summary
============================================================================
Install  4 Packages

Total download size: 1.0 M
Installed size: 2.7 M
Is this ok [y/N]: y
Downloading Packages:
[MIRROR] softu2f-0.4.2-1.fc36.noarch.rpm: Status code: 404 for https://packagecloud.io/danstiner/softu2f/fedora/36/x86_64/softu2f-0.4.2-1.fc36.noarch.rpm (IP: <IP_ADDRESS>)
[MIRROR] softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch.rpm: Status code: 404 for https://packagecloud.io/danstiner/softu2f/fedora/36/x86_64/softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch.rpm (IP: <IP_ADDRESS>)
[MIRROR] softu2f-0.4.2-1.fc36.noarch.rpm: Status code: 404 for https://packagecloud.io/danstiner/softu2f/fedora/36/x86_64/softu2f-0.4.2-1.fc36.noarch.rpm (IP: <IP_ADDRESS>)
[MIRROR] softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch.rpm: Status code: 404 for https://packagecloud.io/danstiner/softu2f/fedora/36/x86_64/softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch.rpm (IP: <IP_ADDRESS>)
[FAILED] softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch.rpm: No more mirrors to try - All mirrors were already tried without success
(2-3/4): softu2f-0  1% [                  ]  75 MB/s |  20 kB     00:00 ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  softu2f-system-daemon-selinux-0.1.0-1.fc36.noarch: Cannot download, all mirrors were already tried without success
[~ (1) ]$

Weird, packagecloud.io seems to have changed how it handles noarch rpm's. Made the packages all arch dependent.
sudo dnf install softu2f should work now for fedora 36

@danstiner it seems that packagecloud now supports fc37 ;-)

I have just installed on fc39 and everything is ok with installation
However I experience #120.


Different user authorisation level

Been curious on how we could manage this.
Users with different permission level will have different ability on the CMS admin interface.
Like a admin should have full control.
A publisher should have publishing rights and any permissions that a lower level would have.
An editor would only have editing rights but not publish.
Could this be done?
Currently, the few ideas that I have at the top of my head is:
Via jquery and use gon to hand over the users permission?
Via opal, keep the user permission on ruby and use opal to write the javascript to manipulate the page?
Via overwriting the whole partial?
Is there other suggestions?

You can't solve authorization flow via partials/js. I suggest you fork the entire project and do required changes on the controller level directly inside the gem.
There's a way to implement basic authorization (briefly mentioned here: https://github.com/comfy/comfortable-mexican-sofa/releases/tag/v1.12.3), but you're better off just hacking directly. It will be much easier I think.


KeyTap is not working on OSX

I'm running the code below on latest OSX (Mojave, 10.14). The issue is that the "arrow down" is not working. I'm testing this by having an instance of Chrome window with a "Select" element open and nothing is moving. robotgo.TypeString("Hello World") is not working either but I was   interested in KeyTab thus I make this issue about KeyTap.
func main(){
for i := 0 ;i < 10; i ++{
time.Sleep(5 * time.Second)
robotgo.KeyTap("down")
fmt.Printf("SUCESS")
}
return
}

Probably related to https://forums.developer.apple.com/thread/103992

Closing is due to can't reproduce.


Create CSS_Table_Styling.md

What is the change?
I have added a file for CSS Table Styling.
Related issue?
closes: #64
Checklist:
Before you create this PR, confirm all the requirements listed below by checking the checkboxes [x]:

[x] I have followed the Code of Conduct.
[ x] I have  checked there aren't other open Pull Requests for the same update/change.
[ x] I have you tested the code before submission.
[x ] I have commented my code, particularly in hard-to-understand areas.
[x ] My changes generates no new warnings.
[ ] I'm Hacktoberfest'21 contributor.

Screenshots (if any)

Congratulations 🎉 PR merged


db.session.commit() is not performed at the end of requests (prev "Confirmation of users")

Update - begins
db.session.commit() is not performed automatically at the end of each request, despite having SQLALCHEMY_COMMIT_ON_TEARDOWN = True in config.py.
This issue was noted after analysing why user confirmation was not working properly.
The app is hosted on heroku (can be reached here), is using Heroku Postgres and is based on this repository, which is forked from the original 17d.
Update - ends
The confirmation link does not update the current_user.confirmed to True and new registered users thus remain unconfirmed.
If the model column is changed by hand via shell, then the user is recognised as confirmed and the app behaves as expected.
Here are the results of my analysis.
By examining the logs, the app behaviour is correct. I have the following lines from registration to confirmation of a new user:

REGISTER, GET, with status 200
2015-08-07T08:50:09.059305+00:00 heroku[router]: at=info method=GET path="/auth/register"
REGISTER, POST, with status 302
2015-08-07T08:50:23.954973+00:00 heroku[router]: at=info method=POST path="/auth/register"
LOGIN, GET, with status 200
2015-08-07T08:50:24.181845+00:00 heroku[router]: at=info method=GET path="/auth/login"
(after clicking on the email confirmation link) CONFIRM, GET, with status 302
2015-08-07T08:50:35.040888+00:00 heroku[router]: at=info method=GET path="/auth/confirm/eyJleHAiOjE0Mzg5NDEwMjMsImlhdCI6MTQzODkzNzQyMywiYWxnIjoiSFMyNTYifQ.eyJjb25maXJtIjoxfQ.7hMYjfDmmwE_8c3kkw7jSdIRLWV-bPSJCCuYsy7bPeY"
(login is required here) LOGIN GET, with status 200
2015-08-07T08:50:35.259303+00:00 heroku[router]: at=info method=GET path="/auth/login?next=%2Fauth%2Fconfirm%2FeyJleHAiOjE0Mzg5NDEwMjMsImlhdCI6MTQzODkzNzQyMywiYWxnIjoiSFMyNTYifQ.eyJjb25maXJtIjoxfQ.7hMYjfDmmwE_8c3kkw7jSdIRLWV-bPSJCCuYsy7bPeY"
LOGIN POST, with status 302
2015-08-07T08:51:04.677048+00:00 heroku[router]: at=info method=POST path="/auth/login?next=%2Fauth%2Fconfirm%2FeyJleHAiOjE0Mzg5NDEwMjMsImlhdCI6MTQzODkzNzQyMywiYWxnIjoiSFMyNTYifQ.eyJjb25maXJtIjoxfQ.7hMYjfDmmwE_8c3kkw7jSdIRLWV-bPSJCCuYsy7bPeY"
CONFIRM GET, with status 302
2015-08-07T08:51:04.947112+00:00 heroku[router]: at=info method=GET path="/auth/confirm/eyJleHAiOjE0Mzg5NDEwMjMsImlhdCI6MTQzODkzNzQyMywiYWxnIjoiSFMyNTYifQ.eyJjb25maXJtIjoxfQ.7hMYjfDmmwE_8c3kkw7jSdIRLWV-bPSJCCuYsy7bPeY"
ROOT GET, with status 302
2015-08-07T08:51:05.156445+00:00 heroku[router]: at=info method=GET path="/"
UNCONFIRMED , with status 200
2015-08-07T08:51:05.868130+00:00 heroku[router]: at=info method=GET path="/auth/unconfirmed"

From what I understand, the auth.before_app_request is redirecting the user to the unconfirmed page.
However the flash message "You have confirmed your account. Thanks!" is displayed (see https://github.com/lucanaso/flasky/blob/master/app/auth/views.py#L72), therefore it looks like current_user.confirm returns True but it does not update the db (see https://github.com/lucanaso/flasky/blob/master/app/models.py#L147).
I have forked the project at commit 17d and after that I have committed only some files for deploying on heroku and requirements.
The app is running on heroku at: https://flasky-forky.herokuapp.com/ you can try it yourself by registering and trying to confirm.
What can be the cause of the user not being confirmed?

I'm currently having a similar issue but a little bit different. I just got past Chapter 9 and now my confirmation emails only work if the user is already signed in. If the user is not already signed in, it just redirects to the login screen and asks the user to "Please log in to access this page." Of course, when the login they reach the unconfirmed page and can ask for a new email but that just seems rather unnecessary. I'm probably missing something rather stupid but I just can't seem to figure out why the confirmation emails only work if I'm already logged in. It's as if the confirm() function is getting skipped because of the @login_required. Everything else seems to work great.

@chelseanderby the login process is required by design. After you follow the confirmation link and login (if needed), you will see a flash message saying that the account is confirmed and you are then redirected to the home page. If the confirmation is not successful you will see a different flash message and still be redirected to the home page. By the way, I'd guess that in most of the cases (say when the confirmation email arrives immediately) the user is already logged in when they click on the link, because they were logged in to trigger the sending of the email.
If you are instead redirected to the auth/unconfirmed route then something is wrong, like in my case.
Let me add an important piece of information (I forgot to add that before, sorry). If I run the same application on localhost it works fine.

@lucanaso Are you using a Postgres database on Heroku, or something else?

@miguelgrinberg yes I am using "Heroku Postgres", plan "Hobby dev", version 9.4.4.
The application succeeds in writing to the database when creating a new user.
When running the app from shell, I can query the db and get the appropriate results. I can also commit changes.
If I explore the db from the Heroku web app, I can see that it has 6 tables and 8 records.

Hmm. Have you made any changes to the configuration? In particular, the SQLALCHEMY_COMMIT_ON_TEARDOWN setting?

The SQLALCHEMY_COMMIT_ON_TEARDOWN is set to TRUE (see https://github.com/lucanaso/flasky/blob/master/config.py#L8).
I forked the latest available commit 17d from your repository,
then I changed the requirement files and added the Procfile. You can find the repository at https://github.com/lucanaso/flasky.
This is the only commit done after your latest 17d: https://github.com/lucanaso/flasky/commit/93d83ea891cd7c5d6edeb7b414d61e6df939fa6e.

@lucanaso Thanks for pointing that out to me. I guess that's just not how I'd imagine it would work because it seems a little counter intuitive to me that you would already need to be logged in earlier for the confirmation email to actually work (and from my workflow tests I did, the user would not be already logged in most cases since following the register path did not logged them automatically).
So I was wondering as to why when I login after the confirmation email link, I get directed to the unconfirmed page rather than the main page?  Only when I am already logged in does the confirmation email work. I mean, I'd guess that's not how it's setup to work but if so, how could I change that? Of course, it's probably something I'm doing wrong, I just want to make sure I actually understand what the app is supposed to do because before I bash my head on the wall for awhile trying to figure it out because my app is almost identical at this stage, minus a couple changes.

In theory it should not make a difference, but could you please try adding a db.session.commit() right after this line?

Indeed, it did not make any difference.
But here I need to ask a side question, before we validate this step.
I made this change on a new branch called flasky/bug/userconfirmation. For updating the application on heroku I then used the command:
git push heroku flasky/bug/userconfirmation (rather than git push heroku master)
followed by the usual heroku run python manage.py deploy and heroku restart.
Is this correct? or I have to push to master (which is the current default)? or I have to make the new branch as the default branch?

News update.
I have authenticated a user by hand and then experimented with it. In fact the application always fail to write to the db and gives no error message.

I submitted a new post, and it got lost. Nothing shows on main, nothing is written in the post table.
I updated my profile, and there was no sign of the changes, both on browser and on the fields in the user table for that user record.
I tried to change the password, and it didn't work.

It looks like only the user registration is actually working, which, I believe, is the only one to have an explicit db.session.commit().
Regarding the previous side note. I have made the latest branch as the default one and re-run the same commands as before, but still no difference.

It looks like the real problem behind this symptom is that db.session.commit() is not performed automatically at the end of each request.
I tested this with user confirmation and with password change, and the fix did work. I added a db.session.commit() here (models.py, for confirmation) and here (auth/views.py, for password change).
I did not see this before in https://github.com/miguelgrinberg/flasky/issues/58#issuecomment-129793204 because the correct way to synch the heroku app to a branch different than master is:
git push heroku origin <your new branch>:master
so in this case:
git push heroku origin flasky/bug/userconfirmation:master
@miguelgrinberg @chelseanderby
I have updated this issue name and description. The question now is:
Why db.session.commit() is not performed automatically at the end of each request, despite using Heroku Postgres and having SQLALCHEMY_COMMIT_ON_TEARDOWN = True in config.py?

I met the same problem.
When I start with
python manage.py runserver

after every sql it log COMMIT.Everything goes fine.
When I start with
gunicorn manage:app

after every sql it log ROLLBACK. I thought in gunicorn SQLALCHEMY_COMMIT_ON_TEARDOWN=True not worked.

I just discovered this issues today.
Has anyone figured it out?

Guys, I need you to tell me which version of gunicorn you are using.
With version 18.0 everything works for me. With version 19.3 (the latest) I can reproduce the behavior described  by @alexli0707 above.
Are you all using version 19? Can you try version 18 and let me know if this addresses the problem for you?
Thanks!

I have 19.3. I have not tried 18.0 yet.

Okay, I think I have figured this thing out, turns out this is a Flask bug.
When the app context is popped at the end of the request, Flask calls all the @teardown_appcontext decorated callbacks. The auto commit feature of Flask-SQLAlchemy is implemented in one of these callbacks (code here). The teardown callbacks get one argument, which is an exception object if there was an error during the handling of the request.
Unfortunately, the logic that the current version of Flask uses to determine if there was an exception is flawed. This has been fixed in master (see the PR) and will be included in the 1.0 release.
Now, why this happens with gunicorn v19 but not v18? The sync worker in version 19 throws an exception before it passes control to the Flask application. This exception is handled, so it does not cause any problem other than exposing the Flask bug, which thinks this gunicorn exception was thrown during the request.

It appears this also prevents users from changing passwords in Flasky.
Does this mean we should just use gunicorn 18 for now until flask 1.0 is released?
Also, according to the docs for Flask-SQLAlchemy, "SQLALCHEMY_COMMIT_ON_TEARDOWN" is not recommended, should we just add commit lines to the effected functions?

I confirm that by using gunicorn 18.0 instead of gunicorn 19.3 (current latest) the issue is not present.
I have tested it with the confirmation case and the password change case. Both of them works fine and it is not required to add the commit at the end of the request.
Thanks to @miguelgrinberg for finding the solution and everyone else for contributing!

I guess this is the same issue @jeffjzx and I encountered over a year ago in #11 . My solution was to change the gunicorn worker to async but afterwards I changed it back to the normal sync worker (can't remember excactly why I did that...) and added an session.commit() to every line of my code where the db is touched. @miguelgrinberg Do you think there will be another Flask release given the last one was fom 2013? Otherwise it would probably be helpfull to mention the solution somewhere before even more people fall for this bug again.
I also don't think using gunicorn 18 is a good solution, there probably were some security fixes since the release of this version. Is there a WSGI server you personally would recommend instead of gunicorn @miguelgrinberg where this problem does not occur?

@miguelgrinberg @lucanaso This issue might be triggered by Flask-SSLify. I just confirmed that by using gunicorn 18.0 with Flask-SSLify 0.1.5 the issue is still there. Then I downgrade Flask-SSLify version to 0.1.4. Then the issue is not present.

@xvweirong this is a Flask bug, it's already fixed in Flask's master branch. See https://github.com/mitsuhiko/flask/pull/1393.

So I have downgraded my Gunicorn to version 18.0 by removing the most recent version and installing this one by pip install gunicorn==18.0. I still get the database problems where it doesn't look like its properly writing because the changes are not shown.
I am using https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-gunicorn-and-nginx-on-ubuntu-14-04 to set up my app and everything works when I run gunicorn --bind <IP_ADDRESS>:8000 wsgi however once I try to use the upstart script with nginx proxy requests, the database errors return.
Any ideas?

My guess is that when you run through upstart you are not using the gunicorn installed in your virtualenv. Make sure you use the full path to the gunicorn executable, something like venv/bin/gunicorn instead of just gunicorn.

Hi Miguel,
I can confirm that the bug also affects the version 18.0 of gunicorn:
Flask == 0.10.1
gunicorn == 18.0
SQLAlchemy == 0.9.7

With or without SSLfy, tested in different environments:

heroku
AWS (Debian)
local (Mac OS X 10.11)

and several databases:

mysql
postgresql
sqlite

In all these cases, the app seems to work properly (flash messages are displayed to the user) but the data is not (always) saved to DB.
Activating the echo of sqlalchemy I note that, in cases of failure to save on the db, a sqlalchemy rollaback is triggered.
The most disturbing thing is that all of the above occurs in almost randomly (!!!): the same views and request sometimes save the data and others do not .... I can not understand the cause of this random behavior.
The only workarond with these framework's versions appears to be the explicitly add db.session.commit () at the end of each request.
The alternative (form me) is to upgrade all the frameworks to the latest version:
Flask-SSLify == 0.1.5
gunicorn == 19.6.0
Flask == 0.11.1
SQLAlchemy == 1.0.13

Also in this case it seems that the random triggering of rollback are gone and the app seems to work properly.
I hope this information will be of help.
Greetings

I am still having this issue on latest of all requirements. Does anyone know of a possible fix or workaround? I have echoing turned on and see rollbacks after almost every query (insert/select/whatever)

The workaround solution is to explicitly commit the database session at the end of each request. The auto-commit option in Flask-SQLAlchemy is not as reliable as I thought.

Gotcha, thanks! It is also worth noting that I experienced the same rollback symptoms under the following circumstances:

add an arbitrary item foo via db.session.add(foo)
access some member variable of that item via foo.bar <-- causes a SELECT statement then a ROLLBACK
call db.session.commit() <-- commits nothing as there was previously a rollback

I'm thinking this has something to do with heroku rather than any application/library logic? This just started happening an hour ago and the affected code has been static for a week or so.
@vincentdo this may be of relevance to you.

@sachabest @miguelgrinberg
What solved the issue for me was switching to uWSGI as the application server. Since then never had any problems with auto-commit and flask.

Closing this issue, as it does not apply to the second edition of the book.


Recursive lists

Is it possible to have recursive lists with this library?

Tried this out, seems to work fine by just wrapping each layer in a new container.


2018-05-15 11:34:43,336 ERROR google.cloud.forseti.common.util.metadata_server(_issue_http_request): Error with request: [Errno -2] Name or service not known

Got this when creating inventory from 2.0-dev.

Seems like one of the API url is not right