I'm setting up a Strapi install in my Apache cPanel (WHM on CentOS 7), and can't find a proper way to deploy it. I've managed to get it running, but when I try to access the dashboard (/admin), it just shows the index page (the one in public/index).
Is this the proper way to deploy Strapi to an Apache server?
Is the "--quickstart" setting only for testing purposes, or can this be used in Production? If so, what are the pre-deployment steps I need to take?
This is for a simple project that requires easy to edit content that will be grabbed via API manually from another cPanel installation.
Reading through the Strapi docs, I could only find deployment information about Heroku, Netlify and other third-party services such as these, nothing on hosting it yourself on Apache/cPanel.
I've tried setting up a "--quickstart" project locally, getting it working and then deploying via Bitbucket Pipelines. After that, just going into the cPanel terminal and starting it - though the aforementioned problem occurs, can't access admin dashboard.
Here's my server.json configuration:
Production
{
"host": "api.example.com",
"port": 1337,
"production": true,
"proxy": {
"enabled": false
},
"cron": {
"enabled": false
},
"admin": {
"autoOpen": false
}
}
Development
{
"host": "localhost",
"port": 1337,
"proxy": {
"enabled": false
},
"cron": {
"enabled": false
},
"admin": {
"autoOpen": false
}
}
There are no console errors, nor 404s when trying to access it.
Edit
Regarding deployment with the --quickstart setting:
there are many features (mainly related to searching) that don't work properly with SQLite (lack of proper index support) Not to mention the possible slowness due to disk speed and raw IOPS of the disk.
A suggestion on how to implement:
Respectfully, to deploy strapi you likely need to:
1. build a docker container for it
2. make a script to deploy it
3. use SSH and do it manually
4. use a CI/CD platform and scripted to deploy it
In summary:
Strapi is not your typical "copy the files and start apache" it's not a flat file system, Strapi itself is designed to be run as a service similar to Apache/Nginx/MySQL ect. They are all services (Strapi does need Apache/Nginx/Traefik to do ssl for it though via proxying)
If you have the index page when you visit /admin it's because the admin is not built.
Please run yarn build before starting your application.
Related
I created a game, and I'm trying to play it with my friends. Since we don't want to pay any ASP.NET Core server space on Azure or whatsoever, we are running the game ourselves and trying to join using a VPN.
I created a Blazor app with an ASP.NET Core server. I modified the launchSettings.json like this:
"profiles": {
"VikingBoardGames.Server": {
"commandName": "Project",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
"dotnetRunMessages": true,
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
"applicationUrl": "https://localhost:7141;http://localhost:5141;https://*:7141" <--- THIS !!
},
[...]
}
Now, from my local computer where I have visual studio, I can access it via http:localhost:5141 AND http://MYIP:7141. which is good.
Then I created a VPN using hamachi. My friend joins the net. He can ping my hamachi IP.
I start the game on visual studio, and visit my IP to see it
He can visit my VPN IP on port 7141, where the page header gets loaded. Thethe "loading..." message appears, but it freezes.
Upon checking the developer tools on chrome on my friends' computer, I see:
DevTools failed to load source map: could not load content for chrome-extensions://gighmmpiobklfepjocnamgkkbiglidomm/browser-polufill.js.map: System error : net::ERR_FILE_NOT_FOUND
And at this point, I don't know how to proceed.
I don't need debugging facilities on his computer, just to be able to join the game and have fun.
What can we do?
So in an application that I'm working on currently I'm trying to proxy requests from a Vue-frontend, to an Express-server. The express server is running on localhost:5000. This is in my vue.config.js:
"devServer": {
"proxy": {
"^/api/": {
"target": "http://localhost:5000",
"ws": true,
"changeOrigin": true
}
}
},
What I can't wrap my head around is why in most cases, sending out requests to my server with just api/routename works just fine. Then in only 2 components it doesn't work. In the components where it does work, a GET request looks like this for example:
axios.get('api/base/verified')
.then...
Then in two other components, according to the same principle of just requesting to api/route-name, I'm getting errors. In development mode, the requests then all of a sudden go out to http://localhost:8080/api..., and when trying to deploy, they go to 5000, but I get this error message:
xhr.js:184 GET http://localhost:5000/api/content/course/5f54f3c60bb7a30017c1abf2 net::ERR_CONNECTION_REFUSED
Does anyone have any idea about what the deal is, and why the proxying is acting so differently, depending on environment and component?
You should always use the url with a leading slash e.g. /api/base/verified See this question. So I guess in your case that 2 components may use in different path.
The reason it's different for different environments is that the proxy is working only in development server that's why they called devServer.
I'm not sure why you got that error it seems there must be another config that can go to port 5000 such as proxy in nginx but ERR_CONNECTION_REFUSED usually means there is no server at that endpoint.
I'm trying to implement the Local Passport Strategy for Hyperledger Composer Rest Server.
To achieve this, I did the following:
First, I installed passport-local by running the following command:
npm install -g passport-local
In my home folder I created a file called "envvars.txt" with the following content:
COMPOSER_PROVIDERS='{
"local": {
"provider": "local",
"module": "passport-local",
"usernameField": "username",
"passwordField": "password",
"authPath": "/auth/local",
"callbackURL":"/auth/local/callback",
"successRedirect": "/",
"failureRedirect": "/",
"setAccessToken": true,
"callbackHTTPMethod": "post"
}
}'
Then, in oder to set the environment variable COMPOSER_PROVIDERS, I ran the following command:
source envvars.txt
After that I started the composer-rest-server using the following specifications:
When I went to localhost:3000/explorer, http-requests were blocked (as expected) because I was not authenticated.
So far so good.
But when I tried to go to address localhost:3000/auth/local (in order to authenticate), this was not possible ... the web browser gave me an error message, the beginning of which was as follows:
{"error":{"statusCode":404,"name":"Error","message":"Cannot GET /auth/local","status":404,"stack":"Error: Cannot GET /auth/local\n at raiseUrlNotFoundError
What went wrong here?
Any help would be much appreciated.
I think your problem is that you are not persisting the data. In the envvars.txt you need to specify where to persist the data because right now there's no database to store the user and password.
Like explained in the official docs you need to persist your data in MongoDB for example.
I'm using rabbitmq-server and fetch messages from it using a consumer written in Scala. This has been working like a charm but since I migrated my RabbitMQ server from a server to another, I get the following error when trying to connect to it:
com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
In addition, the rabbitmq-server logs:
=INFO REPORT==== 18-Jul-2018::15:28:05 ===
accepting AMQP connection <0.7107.0> (127.0.0.1:42632 -> 127.0.0.1:5672)
=ERROR REPORT==== 18-Jul-2018::15:28:05 ===
Error on AMQP connection <0.7107.0> (127.0.0.1:42632 -> 127.0.0.1:5672, state: starting):
PLAIN login refused: user 'my_personal_user' - invalid credentials
=INFO REPORT==== 18-Jul-2018::15:28:05 ===
closing AMQP connection <0.7107.0> (127.0.0.1:42632 -> 127.0.0.1:5672)
I went through every SO questions about authentication problems and found the following leads:
My credentials are wrong
I'm trying to connect with guest from
remote
My RabbitMQ version is not compatible with the consumer
All those leads did not help me. My crendetials are good, I'm not using guest to connect but a privileged user with full access and admin I created and my RabbitMQ version did not change through the migration.
NB: I migrated my RabbitMQ server from a separate server to the same as my consumer, so now the consumer is fetching from localhost. Don't know the consequences but I figured it could help you guys help me.
So I just had a similar problem googled solutions, which is how I found this page. I didn't find a direct answer to my question, but I ended up discovering that rabbitmq has 2 different sets of rights to configure that don't exactly overlap with each other, in my case I had 0 rights for 1 set of rights and admin rights for the other set of rights. I wounder if you could be running into a similar scenario.
Seeing code will make the 2 sets of rights make more since, but first some background context:
My RMQ is hosted on Kubernetes where stuffs ephemeral, and I needed some usernames and passwords to ship preloaded with a fresh rabbitmq instance, well in Kubernetes there's an option to inject a preconfigured broker definition on first startup. (When I say broker definition I'm referring to that spot in the management Web GUI there's an option to import and export broker definitions AKA backup or replace your RMQ live configuration.)
Here's a shortened version of my config with sensitive stuff removed:
{
"vhosts": [
{"name":"/"}
],
"policies": [
{
"name": "ha",
"vhost": "/",
"pattern": ".*",
"definition": {
"ha-mode": "all",
"ha-sync-mode": "automatic",
"ha-sync-batch-size": 2
}
}
],
"users": [
{
"name": "guest",
"password": "guest",
"tags": "management"
},
{
"name": "admin",
"password": "PASSWORD",
"tags": "administrator"
}
],
"permissions": [
{
"user": "guest",
"vhost": "/",
"configure": "^$",
"write": "^$",
"read": "^$"
},
{
"user": "admin",
"vhost": "/",
"configure": ".*",
"write": ".*",
"read": ".*"
}
]
}
Ok so when I originally saw that tags attribute, I assumed o arbitrary value I'll put a self documenting tag there, and that was equivalent to "", which resulted in me having 0 rights to the web management GUI/REST API, while below I had all ".*" so that part had full admin rights. It was really confusing for me because (I was getting a false error message saying I was supplying invalid credentials, but the credentials were correct, I just didn't have access.)
If it's not that then there's also this configuration thing where guest gets limited to localhost access only by default, but you can override it.
Similar problem, we were also facing with different tech stack. In our case tech stack was:
RabbitMQ deployed in Kubernetes (AKS) using Bitnami package in HA mode
Consumer and Producer created in microservice created using Java 8 with Spring Boot Framework using Apache Camel also running in same Kubernetes cluster
We verified below points:
User and password are correct
User associated with required VHOST
Required permission given (administrator tag)
User was able to login from RabbitMQ Web Console
Connectivity on host and port was there from microservice Pod to RabbitMQ service (checked with various tools like telnet)
All code and configuration was absolutely same (as there is same configuration in lower environment working correctly)
Was getting issue:
com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
After much investigation and troubleshoot we found that, the size of username was larger than consumer API supported.
Example, we used username 'productionappuser'. This user was able to login in management web console but was failing from microservice.
We just changed the username to a new user with 8 characters and it started working.
This looks very weird as same user was able to login thus shared findings.
Im sorry if this topic is duplicated, I was not able to find anything similar to this problem.
Our docker clients v17.X + (Docker for Mac & Docker for Linux) are unable to push images under a SSL V2 Registry but are successfully authenticated for pushes under an Insecure V2 Registry (CNAME) that serves the same machine. The output is always the same: unauthorized even if I docker login correctly.
The weird thing is: for our old docker clients (v1.6) we are able to login and push Docker images to a secure v2 Docker registry without any problem using the credentials file stored at ~/.dockercfg. My Nginx appears to be working just fine. Any ideas about what I'm missing here?
_
Im attaching both credentials configuration files, if anyone wants to check:
Docker client: v.17
~/.docker/config.json
{
"auths" : {
"https://secure-docker-registry.intranet": {
"auth": "someAuth",
"email": "somemail#gmail.com"
}
},
"credsStore" : "osxkeychain"
}
Obs: In Docker for Mac's case I tried with 'credsStore' and without it
Obs2: Even allowing anonymous to push images, I'm still getting an unauthorized for this registry.
Obs3: Logs are not very clean about this problem
Obs4: Artifactory is configured using a LDAP Group
Docker client: v.1.6.2
~/.dockercfg
{
"secure-docker-registry.intranet": {
"auth": "someAuth",
"email": "somemail#gmail.com"
},
"insecure-docker-registry.intranet": {
"auth": "someAuth",
"email": "somemail#gmail.com"
}
}
Artifactory Pro's version: 5.4.2