I have been trying to install Craft CMS (free version), but failed each time. At first I attempted to install it on a remote VPS with Ubuntu 20.04 server and MySQL database:
Installation via Composer failed:
In CreateProjectCommand.php line 438:
Could not find package public_html/craft with stability stable.
Then I attempted to install Craft CMS on VPS manually. I got as far as running the installer and entering my username, email and password, but that resulted in "Install failed. Please, check your logs for more info" message. Checked the logs and the problem was as follows:
2022-04-06 22:33:39 [-][-][-][error][craft\base\ApplicationTrait::getIsInstalled] There was a problem fetching the info row: SQLSTATE[42S02>
The SQL being executed was: SELECT *
FROM `info`
WHERE `id`=1
LIMIT 1
2022-04-06 22:33:39 [-][-][-][error][yii\db\Exception] PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'craftdb.inf>
Then on my local machine with Ubuntu 18.04 using Composer got the same error as under VPS. When attempting the manual install I did not get past the error
HTTP 503 – Service Unavailable – craft\web\ServiceUnavailableHttpException
Perhaps it is the free version problem. Or any other ideas?
Related
I was trying to run heroku local or heroku local web and everything was working fine. After importing the data from my heroku remote to my local environment, it started to throw me the following error:
After searching for the solution in some places, I tried restarting the postgresql service with brew services restart postgresql and it started normally but I kept receiving the error. I also tried to delete the postmaster.pid as suggested on this SO post PG::ConnectionBad - could not connect to server: Connection refused but didn't find the file.
Well, finding the solution was easier than I thought.
On this same post (PG::ConnectionBad - could not connect to server: Connection refused) it suggested to check the logs before deleting the file and I did even that I haven't finding the file to be deleted.
When I checked the logs, I came across the following:
So, I checked the heroku's Postgres version and it uses the 12 as default but brew uses the latest, which is the 13th.
To sum up, I did a dump from a Postgre v12 to Postgre v13 and this is incompatible, so I'm going to downgrade my local Postgres to work with my data as expected.
To do that, I did the following:
brew uninstall postgres - to remove v13
brew install postgresql#12 - to install a specific version
brew services start postgresql#12 - to start the new version
Cool fact, I didn't need to restore or modify the data because it wasn't deleted even uninstalling the Postgresql.
Unable to Create site getting error notification
I followed the instructions given here : https://docs.craftercms.org/en/3.1/getting-started/quick-start-guide.html
Steps followed:
I cloned Crafter CMS Docker Compose repo from GitHub and then
I started the container from authoring directory using the docker-compose up command
And then I tried to Create a site in Crafter Studio but I got error notification which says "Unable to Create site: contact system administrator"
I am using Docker Desktop Community in my windows 10 64 bit
Docker - Version 2.0.0.3 (31259)
Crafter CMS - Version 3.1.0
OS - Windows 10 64 bit
Browser: Google Chrome
I expected site creation but I got error notification which says "Unable to Create site: contact system administrator"
Error Nofication :
The problem is RAM. You need to give it 8GB+ of RAM to be able to start all the services (including Elasticsearch).
More on this issue here: https://groups.google.com/forum/#!topic/craftercms/Ei7gJGTEE4I
Also more on the requirements for the authoring env: https://docs.craftercms.org/en/3.1/system-administrators/activities/authoring/authoring-env-performance-tuning.html
I am trying to publish a non-modified ASP.NET 5 project to my freshly installed Ubuntu 15.04 server, but I receive the following message:
An error occurred during publish. AspnetPublishHandler with name
"Custom" was not found
I bound the server to the correct port with:
docker daemon -H 0.0.0.0:5555 &
The connection validation is successful. Anyone has an idea what could be wrong?
Have you tried after the latest release? For some configuration combination the publish profile was getting generated incorrectly.
This is the first time I am deploying my application to Amazon EC2 using Beanstalk .
I am following this guide.
Click (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Ruby_rails.html)
After filling all the info after eb init.
At the step
Select a solution stack.
It is throwing me the same error everytime
$ SignatureDoesNotMatch. Signature expired: 20141211T092422Z is now earlier than 20141212T091944Z (20141212T092444Z - 5 min.)
I am entering the access key and secret as provided by Amazon security credentials.
How can I deploy my application? Any tutorials/articles where I can find some other way around?
Found the solution,It was happening because of server clock and my local machine time was not synchronized.
It can be done by installing ntp tools on your machine.
Article followed
http://www.cyberciti.biz/faq/howto-install-ntp-to-synchronize-server-clock/
I experienced this issue today with ami-ada2b6c4 creating a new instance in a VPC without a public IP - logged in via SSH and the terminal hangs on Installation started.
I used Ctrl-C to interrupt and this printed on the terminal:
Installation started ^CTraceback (most recent call last):
File "datastax_ami/ds4_motd.py", line 239, in <module>
run()
File "datastax_ami/ds4_motd.py", line 228, in run
waiting_for_status()
File "datastax_ami/ds4_motd.py", line 100, in waiting_for_status
time.sleep(5)
KeyboardInterrupt
I followed a link to github posted by joaquin for a similar problem and added an entry to /etc/hosts. Logged off the instance and then reconnected. this time, got a different error.
Raiding complete
Waiting for nodetool...
The cluster is now in it's finalization phase. This should only take a moment...
Note: You can also use CTRL+C to view the logs if desired:
AMI log: ~/datastax_ami/ami.log
Cassandra log: /var/log/cassandra/system.log
Note: Ownership information does not include topology; for complete information, specify a keyspace
Datacenter: Solr
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns Host ID Token Rack
UN 10.0.10.92 53 KB 100.0% c010f1d3-3d74-4c2b-ae88-9e3fecfc447c -9223372036854755808 rack1
Opscenter: http://10.0.10.92:8888/
Please wait 60 seconds if this is the cluster's first start...
Tools:
Run: datastax_tools
Demos:
Run: datastax_demos
Support:
Run: datastax_support
------------------------------------
DataStax AMI for DataStax Enterprise
and DataStax Community
AMI version 2.5
DataStax Enterprise version 4.5.2-1
------------------------------------
These notices occurred during the startup of this instance:
[ERROR] 10/15/14-18:16:08 git pull:
error: Failed connect to github.com:443; Connection timed out while accessing https://github.com/riptano/ComboAMI.git/info/refs
The security group does allow access to the internet - I was able to sudo apt-get update, for example.
A couple of learnings from my experience. Joaquin from Datastax was very helpful with his suggestions.
I passed in userdata using the advanced config in AWS Management GUI -
--clustername EIP_ami --totalnodes 3 --version enterprise --username some.guy_some.com --password changeme --searchnodes 3
but didn't change the number of instances to 3 in the GUI so only one node was created. this may have contributed to the problem.
After interrupting the initial hanging installation -
added this entry to /etc/hosts:
127.0.1.1 ip-10-0-1-234
added an elastic IP to the instance and rebooted
I got to the 2nd error:
These notices occurred during the startup of this instance:
[ERROR] 10/15/14-18:16:08 git pull:
error: Failed connect to github.com:443; Connection timed out while accessing https://github.com/riptano/ComboAMI.git/info/refs
When I got to a bash prompt, I tested the git pull manually per Joaquin's advice:
ubuntu#ip-10-0-1-234:~/datastax_ami$ git pull
Already up-to-date.
per Joaquin:
Yes, that error message will stick around for the life of the machine.
Perhaps the git pull issue was a fluke.
Nodetool status says the node is up and acting normally. So, the learning here is to ignore the errors - none of them seem to affect the creation or operation of the node.