Looks like is back online. 
1 Like
Migration to new servers
Hey folks.
I’m, currently migrating all of my services to new servers with different IPs.
for matray: I will keep both servers active for a few days until DNS have updated for everyone.
There should be no / minimal downtime.
In case of unexpected problems, give me a holler.
(I have no idea where to properly announce this, so I’m just gonna do it here and necro this thread)
7 Likes
Quick heads-up. Server just had a fauilty SSD and my provider is replacing it. Server and thus this service will have unexpected downtime until everything is restored because I chose to take it down as a safety precaution. Reason: Server has RAID but it will take some time to re-mirror it to new disk and I don’t want any load on the server while it does that. Give it four hours max.
Update: Aaand It’s done.
3 Likes
New heads-up.
As discussed here: mnserver github, twitter has started locking down their feeds/API.
Consequently, the twitter feed in matray won’t work anymore.
Right now, we don’t plan on fixing this.
My personal opinion on this is: Screw twitter. If they want to keep worsening their services and thus loosing their userbase, let them.
4 Likes
https://manjaro.news stopped working recently with some kind of security error, which also results in matray not working. Is there an update available for this?
Looks like the domain owner did not extend the domain.
You cannot judge from opening the domain in a browser.
Important certificate detalis
Not Before Tue, 12 Mar 2024 10:28:59 GMT
Not After Sat, 07 Sep 2024 21:59:00 GMT
Issued by a valid norwegian issuer https://buypass.no and their english web https://www.buypass.com/
Huh, I took a guess because the tls cert is for “buypass”. The name looked like a domain reseller.
So, we need to wait for the nerd.
I just got error400
The domain is with hidden details…contact number is german.
The ip address is only v6…and points to server in Ukraine.
on what exactly?
that is expected usually, this is how it works, people let their registrar manage and fill these domain information
no
The IP seems indeed to point to Ukraine, but is that relevant?
server is ok and service run (well ?)
curl 'https://manjaro.news' -H 'Content-Type: application/json' -d '{"Categories":"Announcements"}'
but what are right parameters for a good test ???
curl 'https://manjaro.news' -H 'Content-Type: application/json' -d '{"Branch":"stable", "Category":"Announcements"}'
curl 'https://manjaro.news' -H 'Content-Type: application/json' -d '{"Branch":"stable", "Category":["Stable Updates"]}'
curl 'https://manjaro.news' -H 'Content-Type: application/json' -d '{"Category":["Stable Updates","Announcements"]}'
always empty array 
Omano is right, i tried with a web browser which is not expected to work. So an error 400 is actually good, since it is a bad request, a request from a browser.
And MATRAY seems to work, it shows the latest topics.
Not for me. It’s broken here. Here’s the notification I’m seeing.
I hacked matray’s Vala code a bit locally to add some more output that shows info from the web request and response. Here’s my custom output from my local fork of matray:
Error occurred fetching news:
Unspecified proxy lookup failure
Request URI:
https://manjaro.news/
Request headers:
Content-Type = application/json
Accept-Encoding = gzip, deflate
Request body:
(null)
Response headers:
Response body:
(null)
I’m not sure why it says “Unspecified proxy lookup failure”, but navigating to the URI https://manjaro.news/ with Firefox does show an error, so basically my little experiment didn’t reveal much to me other than the request URI.
- I am thinking IPv4 vs IPv6, name resolution errors … and something I have not thought of.
- I found out cached news.
- traceroute dies before reaching the service
Until such time the manjaro.news service is available you are free to use mine.
Simply change the location in the mntray config to http://sx.nix.dk:10111/
Taken down - no longer needed
1 Like
Thanks for that insight. I did notice that the issue seemed to start around the same time that my ISP enabled IPv6 support, but I assumed that must be a coincidence, since if it worked before and the ISP didn’t disable IPv4, it should still work after.
Thanks for this as well. I switched to yours and it works well.
2024-06-26 edit: Looks like your server stopped working. I’m getting “Connection Refused” now.
Hey there everybody.
Sorry for not responding for so long but I don’t seem to get any notifications from this site. Will try using an alternative email in my profile, maybe my normal provider spam-filtered all mails from here… sorry for the delay 
So, let’s get to it…
First, I closely monitor uptime and availablity of manjaro.news with two separate monitoring tools, Grafana and updown.io.
Both didn’t report any major problems eversince I set them up.
So whatever happend to you guys, I don’t know. I don’t do request logging (for obvious privacy reasons).
I still use matray with my domain and it still works great. You can always give me a PM when there’s something wrong under matrix at: @weidenwiesel:matrix.org
I’ll respond faster there than I will over here.
If you still face issues right now, please send me a PM on matrix and I’ll see what I can do 
You can also check the public uptime and apdex of manjaro.news here: Manjaro News status page
There was a minor IPv6 issue on the 5th of June (for 50mins), but apart from that, no downtime, connection or latency issues at all.
Moreover, as you can see, the domain is available over IPv4 and IPv6.
Second, the site only exposes a small API that responds to valid POST requests. Opening https://manjaro.news with a webbrowser will result in invalid responses (400 most likely). This is due to the fact, that the site does not respond correctly to normal HTTP requests.
If you want to verify for yourself whether it works you can run the following command via shell:
curl -X POST https://manjaro.news/news -d '{"MaxItems":15,"Categories":["All"]}'
Important: Please refrain from using this code snippet to run repeated uptime checks yourself. Once/Twice is fine, but don’t put it in a cronjob please. As I said above, I already closely monitor it and will be notified when there’s something wrong. The issue you faced probably had nothing to do with my server but a connection issue with your ISP or whatelse.
Third, I just read about you discussing the certificate. The certificate issuer is well-respected. The reason why I’m using buypass and not letsencrypt is because buypass fully supports ocsp-stapling which I use for some of my more security-sensitive services. I use dehydrated (GitHub - dehydrated-io/dehydrated: letsencrypt/acme client implemented as a shell-script – just add water) for updating the certificates and monitor cert expiry and renewal via Grafana. Again, there were no errors eversince i set it up.
Fourth, yes, the server is in Ukraine (at vsys.host). I know, there is a war going on, but I have 3 separate backups at 3 separate locations and they never had any network issues for the past 2 years, so I’m not really worried
Last but not least, feel free to continue using my domain. I’m still dedicated to keeping it up and am, unlike anyone else in here, still the “official” successor of moson, who originally created and hosted the whole thing and I specifically issued a fittingly named and pricey domain for the whole thing.
I therefore advise against using anyone elses alternative domain in your settings.
Your choice of course.
I hope I could clear up a few things. If there are any more questions or problems, feel free to contact me here on on matrix.
Cheers
6 Likes
[alex@alex-pc ~]$ curl -X POST https://manjaro.news/news -d '{"MaxItems":15,"Categories":["All"]}'
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
[ble: exit 92]
[alex@alex-pc ~]$
Unfortunately, the service does not work even now, today, on Manjaro. I will message you on Matrix as well, and help you troubleshoot. Thank you for your service.
Well…it does here
[teo@teo-lenovo-v15 ~]$ curl -X POST https://manjaro.news/news -d '{"MaxItems":15,"Categories":["All"]}'
[
{
"GUID": "forum.manjaro.org-topic-162679",
"URL": "https://forum.manjaro.org/t/testing-update-2024-05-27-kernels-plasma-6-0-5-kde-gear-24-05-gnome-46-2-pipewire-1-0-7/162679",
"Title": "[Testing Update] 2024-05-27 - Kernels, Plasma 6.0.5, KDE Gear 24.05, GNOME 46.2, PipeWire 1.0.7",
"Category": "Testing Updates",
"PublishedDate": "2024-05-27T07:51:09Z"
.................
................
This is from the Telefonica in Germany.
So it was either a temporary thing with the server, or dns change, or ddos, or maybe your isp was misconfigured for some route.
p.s. and it also works from proton vpn
1 Like
To clarify: There is no temporary problem with the server.
Again, I closely monitor all of my services using 2 different monitoring tools, a full Grafana suite and updown.io.
Both test the manjaro.news API from up to 6 different locations all over the world every 3-10mins. Both check for a valid json response. I additionally collect realtime server metrics (cpu, mem, network, io, etc) via prometheus and use alermanager to notify me about any abnormalities.
If there was anything wrong with the site or the server, I would know.
@Buju seems to get some kind of protocol error, so it seems, for some reason, he is doing invalid requests to the server.
@Buju Sorry, but that’s just how it is 
You could still give me a ping over at matrix but I fear there’s not much I can do because I really don’t log requests and am therefore not able to debug problems like these.
There may be no temporary problem with the server, but it looks like there is a problem with the client. It seems to be related to IPv6 requests. If I add the -6 argument to the curl command above, the request works and returns correct data. If I omit it, the request fails with the same message I posted above. So, it looks like matray doesn’t make a correct request. I’m not sure exactly what the -6 argument does, but it’s related to IPv6.
Here’s what the curl manual says it does:
-6, --ipv6
Use IPv6 addresses only when resolving hostnames, and not for example try IPv4.
Your resolver may respond to an IPv6-only resolve request by returning IPv6 addresses that contain "mapped" IPv4 addresses for compatibility purposes. macOS is known to do this.
Providing --ipv6 multiple times has no extra effect.
Example:
curl --ipv6 https://example.com
See also --http1.1 and --http2. This option is mutually exclusive to -4, --ipv4.