Owncloud Cannot disable upgrade/update - owncloud

We currently trying to use Owncloud for our office storage and everything goes smoothly until there are update for owncloud server and the app asking everyone who visiting the site. Even before login, owncloud asking for visitor to update to latest version.
Outside of several changes we employ to Owncloud core source to suit our requirement, there are also concern from security policy(which is best practice in most cases) that no one can update the apps except admin. Even so, admins must test it before deployment in to production.
In documentation, there are several configs item to configure update, here is our configs to disable update
`
'upgrade.disable-web' => false,
'upgrade.automatic-app-update' => false,
'updatechecker' => false,
'updater.server.url' => '127.0.0.1',
`
Yet update notice still occurred, then our team try to block all outgoing traffic and new error screen showing up several days latter with new error 500 message, here what we found in log:
{"reqId":"L75LhvGcWcDjxjqxL3sD","level":3,"time":"2022-11-11T04:47:08+00:00","remoteAddr":"xxx.xxx.xxx.xxx","user":"--","app":"index","method":"GET","url":"\/","message":"Exception: {\"Exception\":\"OC\\\\NeedsUpdateException\",\"Message\":\"\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/legacy\\\/app.php(124): OC_App::loadApp()\\n#1 \\\/var\\\/www\\\/owncloud\\\/lib\\\/base.php(904): OC_App::loadApps()\\n#2 \\\/var\\\/www\\\/owncloud\\\/index.php(54): OC::handleRequest()\\n#3 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/legacy\\\/app.php\",\"Line\":188}"}
Anyone have same issue with us? If this keep continue, I think we will dump Onwcloud completely and build ourself.
Thanks

Related

Azure database works on localhost, but not when used with azure service app

So I've been trying to publish my first project to azure. I've got everything set-up, a service app and a sql database.
My initial page loads properly(It's the standard view for a .net core web application).
The first thing I need to do is register a new user. Whenever I try through my azure app (myapp.azurewebsites.net) it fails and the logs says it's db related.
However I try the same thing by running the application on my machine in production environment, again connected to the azure sql server and everything works perfectly. I can register users, I can create posts, I can edit them. The allow access to azure services option is turned on. This error is from the eventlogs. I have not included the stacktrace.
Category: Microsoft.EntityFrameworkCore.Query EventId: 10100 RequestId: 800001be-0000-ba00-b63f-
84710c7967bb RequestPath: /Identity/Account/Register SpanId: |1e5a93ae-43f424904f38ea9f. TraceId:
1e5a93ae-43f424904f38ea9f ParentId: ActionId: c3430236-e61c-4785-a3c3-4f60ba115b6e ActionName:
/Account/Register An exception occurred while iterating over the results of a query for context type
'MyApp.Data.ApplicationDbContext'. Microsoft.Data.SqlClient.SqlException (0x80131904): Server
name cannot be determined. It must appear as the first segment of the server's dns name
(servername.database.windows.net). Some libraries do not send the server name, in which case the
server name must be included as part of the user name (username#servername). In addition, if both
formats are used, the server names must match.
Those are the different ways I tried to add the connection string to the appsettings.json file. (Server name, catalog, user and password have been replaced, they are written correctly in the appsettings file)
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user#server;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
Alright so after a day and a half, I finally managed to fix it. The solution is rather simple and it is most likely my newbie mistake, that caused so much trouble.
I was following a tutorial for setting up the application and database connection after that. In the tutorial, the connection string that was being used, was the default one, found in the "myApp -> Configuration -> Connection strings", the format was:
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
This one was working in the guide, but not for me. So what I did, was go to my "sqldb -> connection strings" and copied the one provided there. I then went back to the app configuration and added it as a new configuration string using SqlServer as the Type.
This string was in the format:
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
After that, the app started working properly.

How do I Re-route Ghost Blog Admin URL without modifying the API Address?

Ghost blog platform has a setting that allows you to change the admin panel login location (which starts as: https://whateveryoursiteis.com/ghost). Methodology / docs for changing that setting can be found here: https://ghost.org/docs/config/#admin-url
However — when using the above methodology the API Url that is used for Search etc etc is ALSO modified meaning all requests to the ghost API will also be forwarded to the alternate domain (not just the admin access).
My question is — what is the best way to achieve a redirect of the admin URL to a different Domain / protocol while allowing the API url used by Ghost to remain the same?
More background.
We are running ghost on top of GKE (Google Kubernetes Engine) on a Multi-Region Ingress which allows us to dump our CloudSQL DB down to a SQLite file and then build that database into our production Docker Containers which are then deployed to the different Kubernetes nodes that are fronted by the GCE-Ingress load balancer.
Since we need to rebuild that database / container on content change (not just on code change) we need to have a separate Admin URL backed by Cloud SQL where we can persist / modify our data which then triggers the rebuild on our Ci pipeline via Ghost Webhooks.
Another related question might be:
Is it possible to use standard ghost redirects (created via: https://docs.ghost.org/concepts/redirects/) to redirect the admin panel URL (ie. https://whateveryoursiteis.com/ghost) to a different domain (ie. https://youradminsite.com/ghost)?
Another Related GKE / GCE-Ingress Question:
Is it possible to create 301 redirects natively using Kuberentes GCE-Ingress on GKE without adding an nGinx container etc?
That will be my first attempt after posting this — but I figured either way maybe it helps another ghost platform fan down the line someplace — I will attempt to respond back as I find answers to those questions (assuming someone doesn't beat me to it!).
Regarding your question if it's possible to create 301 redirects without adding a nginx container, I can suggest to use istio, find out more information about traffic routing here.
OK. So as it turns out the Ghost team currently has things setup to point API connections at the Admin URL. So if you change your Admin URL expect your clients to attempt to connect to that URL.
I am going to be raising the potential of splitting these off as a feature request over on the ghost forums (as soon as I get out from under pre-launch hell on the current project).
Here's the official Ghost response:
What is referred as 'official docker image' is not something that we
as a Ghost team support.
The APIs are indeed hosted under the same URL as the admin and that's
by design and not really a bug. Introducing configuration options for
each API Ghost instance hosts would be a feature and should be
discussed at our forum first 👍 I think it's a nice idea to be able to
serve APIs from different host, but it's not something that is within
our priorities at the moment.
In case you need more granular handling of admin site, you could
introduce those on your proxy level and for example, handle requests
that are coming to /ghost/api with a different set of rules.
See the full discussion over here on the TryGhost GitHub:
https://github.com/TryGhost/Ghost/issues/10441#issuecomment-460378033
I haven't looked into what it would take to implement the feature but the suggestion on proxying the request could work... if only I didn't need to run on GKE Multi region (which requires use of GCE-Ingress which doesn't have support for redirection hah!). This would be relatively easy to solve the nGinx ingress.
Hopefully this helps someone — I will update as I work through the process. As of now I solved it by dumping my GCP CloudSQL database down to a SQLite db file during build time (thereby allowing me to keep my admin instance clean and separate from the API endpoint — which for me remains the same URL).

Cannot delete old MariaDB 5.5.4 End-of Life on 31.01

Migrated successfully to new MariaDB Service. Kept the old just in case.
Now I am not able to delete the old service via Web Console.
Message: Delete App bindings and Service keys first.
But: There are no app bindings and service keys cannot be deleted due to 'internal server error'.
So what's to do?
I am confident you already solved this, but just in case. You will have to reach out to the Swisscom Support System and send them a message at the bottom of this page: https://developer.swisscom.com/support
They will be able to delete the service instance for you.
PS: don't forget to include your Organization / Space / Service Name in that correspondence (not here)

Setting up load-balancer based on authenticated users

I'm trying to set up a loadbalancer that would redirect to specific version of an application certein users. So far i was using Blue/Green deployment strategy (so once i made new version of an app i created new environment and redirected traffic there). Now i would like to change this approach. I want to be able to specify users (more experienced or whatever) that would see new site after authentication while the others would still be redirected to old one. If something goes wrong with new version all users will see old version. Currently my loadbalancing is made in apache and authentication is done on application level. So is this even possible? I know i could hardcode it in application but what if there is a bug in new feature and new users are still being redirected there? I would then need to stop application for all users and rollback to old version and that's bad i guess. I was thinking about using external CAS however didnt find any information if it would be possible then. So i would like to ask is it possible and are there any tools (maybe some apache plugin) for that purpose?
Here's a working solution with nginx
create conf.d/balancer.conf
put the code into it (see below)
docker run -p8080:8080 -v ~/your_path/conf.d:/etc/nginx/conf.d openresty/openresty:alpine
use curl to play with it
balancer.conf:
map $cookie_is_special_user $upstream {
default http://example.com;
~^1$ http://scooterlabs.com/echo;
}
server {
listen 8080;
resolver 8.8.8.8;
location / {
proxy_pass $upstream;
}
}
testing
curl --cookie "is_special_user=1" http://localhost:8080
It would return the contents of scooterlabs.com dumping the request it receives
curl http://localhost:8080
Produces the contents of example.com
explanation
the idea is that you set a special cookie to the users you treat as special by the backend app after they get authorized as usual
of course it would only work if both app versions are served on the same domain so that the cookie is seen by both versions
after that you balance them to a desired server depending on the cookie value
you can easily disable such routing by tweaking your nginx config file
with this approach you can come up with even more complex scenarios like setting random cookie values in the range 1-10 and then gradually switching some of the special users in your config file i.e. start with those having value 1, after that 1-2 etc

SIP extention created by FusionPBX can not login into softphone

I have a FreeSWITCH v1.6.13 on my Debian 8( From git) and it is OK.
After that i installed the last FusionPBX to manage my PBX telephony FS.
But it gives me error : 403 You must define a domain called x.x.x.x in your directory...
Both i installed by FusionPBX guid in their web site.
FreeSWITCH and FusionPBX.
Im going crazy cause about 4 days i Am working and not a good result yet.
I know Fusion store data in DB and i give him a Pgsql user name and password.( not the default one it suggest after ./install command) and also FS with --enable-core-pgsql-supprt in ./configureaiton with -C.
And i searched a lot, and all says as this link.
But when i go to sip status from FusionPBX, it says that my ip is correct, and also i did what they say but no success.
Just one time it worked! and i did not why it work.
And after it does not work and again says 403 you must ....
And after that i create an extention, i go to FS terminal and type user_exist 101 (user i created in fusionpbx)it return me false.
Can it be DB issue?
I do not know why just one time it worked and after i after that again gave me 403 error.
Cause i did changed a lot i could not understand what was the cause to work it.
Is it a bug?
What exactly i am doing wrong??
Really any help will appreciate.
EDIT 1 :
My softphone is android zoiper for test the created extention in fusion.
Make sure you are using the "Extension" number as the username in zoiper. Also go to the extension's settings page to see the current password for that extension. I have used Zoiper on my android phone with FusionPBX. So I know it will work.
Zoiper account settings will be:
Account Name: Any name.
Hostname: ip/hostname of FusionPBX
Username: extension number
Password: extension password.
One thing that confused me a lot when I first tried fusionpbx is the "Users" vs "Extensions". From what I can tell "Users" are only for logging into the web UI of FusionPBX, for things like checking voicemail and managing other features. The "Users" are not SIP users.