Viestialustana vianhallintajärjestelmät

All right, thanks for responding anyway!

3. maaliskuuta 2022 klo 18.54
Sijainti: Vianhallintajärjestelmät: Github

All right, thanks for responding anyway!

Vastaa viestiin sen kontekstissa (Github)

”Please enable cookies” from ra.co (on Cloudflare)

3. maaliskuuta 2022 klo 18.15
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Cloudflare, Resident Advisor

Subject of the issue

I’m getting a "title":"Please Wait... | Cloudflare" and "description":"Please enable cookies." from Resident Advisor’s podcast episode pages.

Steps to reproduce

curl -sL 'https://api.microlink.io/?url=https%3A%2F%2Fra.co%2Fpodcast%2F821'

Expected behaviour

Not sure what the description should be, but og:title is ”RA.821 Sunju Hargun ⟋ RA Podcast”, so I’d expect that for the title.

Actual behaviour

{
  "status":"success",
  "data":{
    "title":"Please Wait... | Cloudflare",
    "description":"Please enable cookies.",
    "lang":"en",
    "author":null,
    "publisher":"Amazon",
    "image":{
      "url":"https://ra.co/cdn-cgi/images/trace/managed/js/transparent.gif?ray=6e6278b6dae58c30",
      "type":"gif",
      "duration":0.1,
      "size":42,
      "height":1,
      "width":1,
      "duration_pretty":"100ms",
      "size_pretty":"42 B"
    },
    "date":"2022-03-03T12:45:50.000Z",
    "url":"https://ra.co/podcast/821",
    "logo":null
  },
  "statusCode":403,
  "headers":{
    "date":"Thu, 03 Mar 2022 12:45:50 GMT",
    "content-type":"text/html; charset=UTF-8",
    "cf-chl-bypass":"1",
    "permissions-policy":"accelerometer=(),autoplay=(),camera=(),clipboard-read=(),clipboard-write=(),fullscreen=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()",
    "cache-control":"private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0",
    "expires":"Thu, 01 Jan 1970 00:00:01 GMT",
    "x-frame-options":"SAMEORIGIN",
    "expect-ct":"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"",
    "set-cookie":"__cf_bm=5KE3AuPAXjTbtqg1orpJUhrCEm74SBvBFamivvHlWzk-1646311550-0-ATV5QxpiBmqa/YdWk1PqMtqR3dvdRyhnoC1vmjBc6/Vx+nDJU9je3vRWZ4TawNbqXf994S1qOAZ9v5WWtlWPCbbjskKZYXuIEV8+aaohm1vE; path=/; expires=Thu, 03-Mar-22 13:15:50 GMT; domain=.ra.co; HttpOnly; Secure; SameSite=None",
    "vary":"Accept-Encoding",
    "server":"cloudflare",
    "cf-ray":"6e6278b6dae58c30-EWR",
    "content-encoding":"gzip"
  }
}

Other info

Prior to discovering microlink.io I’ve used ad hoc hacks to fetch the titles, and had similar problems with the site then; they’re probably doing stupid things at their end, so I don’t know if this is fixable.

(Also, sorry if this wasn’t the right issue tracker, as I couldn’t figure out the canonical place for issues with just using the API from the command line.)

Vastaa viestiin sen kontekstissa (Github)

auth login exits with status 0 even for a non-working URL

4. helmikuuta 2022 klo 11.14
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Steps to reproduce

Note the literal use of example.com here; don’t replace it with an actual, working MM instance URL.

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl  auth login http://example.com --name example --access-token 123456890abcdefghijklmnopq`
# echo $?

What I expect happen

For a non-zero exit status to be printed.

What happens instead

The exit status is 0.

Vastaa viestiin sen kontekstissa (Github)

–config with auth login only works correctly with ”config” as filename

30. tammikuuta 2022 klo 16.24
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Go, Mattermost

Issue

When a custom configuration file is supplied via --config to auth login, and reading credentials from the given file doesn’t succeed, an attempt is made to create the supplied directory path. This path is constructed by stripping a fixed ”config” (without a directory separator) from the user-supplied path.

When the custom configuration file doesn’t exist, this results in an unnecessary mkdir when the given filename ends with the hardcoded value of ”config” (case 1 below), or that plus a ”is a directory” failure when it doesn’t (case 2).

If the custom configuration file does exist, the useless mkdir is still triggered when the given filename ends with the hardcoded value of ”config” (case 3), or a ”not a directory” failure when it doesn’t (case 4).

Cause

The problematic mkdir call is issued here. I have no experience in Go, but instead of the TrimSuffix() call nested on that line, I think there should be a Go equivalent of a dirname instead, using the user-supplied path as parameter, and without referencing the value of configFileName (the source of the hardcoded ”config”).

Steps to reproduce

Case 1

A useless, empty mmctl_ directory gets created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/mmctl_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:27 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:27 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:27 mmctl_
-rw-------  1 mattermost mattermost   244 tammi  30 15:27 mmctl_config

/tmp/mmctl_test/mmctl_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:27 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:27 ..

Case 2

Saving the credentials fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com--name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: cannot save the credentials: open /tmp/mmctl_test/test: is a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 20
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:31 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:31 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:31 test

/tmp/mmctl_test/test:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:31 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:31 ..

Case 3

A useless, empty test_ directory is created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test_config
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:58 .
drwxrwxrwt 22 root       root       12288 tammi  30 15:58 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:58 test_
-rw-rw-r--  1 mattermost mattermost   244 tammi  30 15:58 test_config

/tmp/mmctl_test/test_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:58 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:58 ..

Case 4

Saving the credentials again fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: mkdir /tmp/mmctl_test/test: not a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 16
drwxrwxr-x  2 mattermost mattermost  4096 tammi  30 16:00 .
drwxrwxrwt 22 root       root       12288 tammi  30 16:00 ..
-rw-rw-r--  1 mattermost mattermost     0 tammi  30 16:00 test

Vastaa viestiin sen kontekstissa (Github)

–quiet not honored by auth login (possibly others)

30. tammikuuta 2022 klo 15.02
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Steps to reproduce

  1. Log in using mmctl.

What I expect to happen

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq
# 

What happens instead

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq

  credentials for "example": "Personal Access Token@https://example.com" stored

# 

Potential cause

From looking at the code, output and --quiet are implemented in Printer, but auth and a few other places appear to use fmt.Printf() directly instead.

Vastaa viestiin sen kontekstissa (Github)

JSON files attached to a card (with .json filename extension) are empty when downloaded

28. tammikuuta 2022 klo 14.01
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Apache, Brave, Firefox, Snap, Ubuntu, Wekan, Wikipedia

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

  • Did you test in newest Wekan?: 5.90
  • Did you configure root-url correctly so Wekan cards open correctly? yes
  • Operating System: Ubuntu 20.04
  • Deployment Method: snap
  • Http frontend if any: Apache
  • What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

  1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
  2. Open a card in Wekan.
  3. Select + from the Attachments section.
  4. Select ”Computer” from the popup.
  5. Select example.json.
  6. With the JSON file now attached to the card, select to ”Download” it.
  7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

  • Deleting the attachment seems to work.
  • The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Vastaa viestiin sen kontekstissa (Github)

Also: #19974

16. tammikuuta 2022 klo 20.03
Sijainti: Vianhallintajärjestelmät: Nextcloud

Also: #19974

Vastaa viestiin sen kontekstissa (Nextcloud)

I think my HA is also affected by this

16. tammikuuta 2022 klo 14.45
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant, Kodi

I think my HA is also affected by this. I haven’t done any firewall snooping and I’m not using pFsense, but I also have a timer based on Kodi’s ”turn_off” event, and the symptom of repeated ”turn_off” events match. The workaround from @ChopperRob above also seems to work.

(Probably unrelated, but I’ve also noticed that my ”turn display on when Kodi becomes idle” stops working when my LAN/WLAN gets very congested (such as when doing backups over the network). I’m using ”idle” because the log never shows a ”turn_on” event from Kodi; just ”idle”, ”playing” and the intermittently incessant ”turn_off” events.)

Vastaa viestiin sen kontekstissa (Github)

This also seems to be fixed in VLC 3.0.9.2-1

2. tammikuuta 2022 klo 20.09
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: VLC

Seems to be fixed in VLC 3.0.9.2-1 (Ubuntu 20.04); at least I haven’t been able to reproduce it anymore.

Vastaa viestiin sen kontekstissa (Launchpad)

Reproducible here

2. tammikuuta 2022 klo 20.04
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: VLC

Same ”double free or corruption (!prev)” reproducible here too (VLC 3.0.9.2-1, Ubuntu 20.04), even more easily: the position doesn’t matter, and the first attempt to screenshot is already enough to trigger the issue.

I came across this when trying to screenshot a Superman cartoon I downloaded from Internet Archive [1].

* [1] https://archive.org/download/dom-6746superman-episode7-theundergroundworld512kb/dom-6746superman-episode7-theundergroundworld512kb.mp4

Vastaa viestiin sen kontekstissa (Launchpad)

« Uudempia - Vanhempia »