CKAN creates a default user when it starts the development server.
ckan -c /etc/ckan/production.ini run --host 0.0.0.0 --port 5000
If the the default user is deleted and ckan is restarted again, it appears again. I don't want to have a default sysadmin user since I have my own admin user
The site_user is created on startup and its used only for internal services. If it gets removed it will be recreated on every get_site_user call
Related
The Following is my EC2 User Data:
#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
In Security Group SSH 22 Port and HTTP 80 Port is Open.
Yet when I try accessing http://public_ip_of_instance the HTTP Apache page doesn't load.
Also, on the Instance Apache is not installed when I checked sudo systemctl status httpd.
I then manually tried it on the EC2 Server and it worked. Then I removed it through yum remove as I wanted to see whether User Data works.
I stopped the Instance and started again but I observed that the User Data Script doesn't work as I am unable to access http page through browser and also on Instance http is not installed.
Where is the actual issue? Some months back this same thing worked on another instance I remember.
Your user data is correct. Whatever is happening with your website is not due to the user data code that you provided.
There could be many reasons it does not work. Public IP of the instance has changed, as always happens when you stop/start the instance. Instance may have per-existing software that clashes with httpd.
Here's some general advice on running UserData once or each startup.
Short answer as John mentioned in the comments EC2's only run the UserData (aka Bootstrap) script once on initalization.
The user data Bash/Powershell is Infrastructure-As-Code. You deploy the script and it installs and configures the machine.
This causes confusion with everyone starting AWS. When you think about it though it doesn't make sense to run the UserData script each time when the PCs already been configured.
What people do often instead is make "Golden Images" (aka Amazon Machine Images - AMI's) of pre-setup EC2s, typically for PCs that take long time to install/configure. The beauty of this is you can setup AutoScaleGroups to use the images which saves any long installation during a scale up event.
Pro Tip: When developing an UserData script run through and test it manually on the EC2. Trust me its far quicker than troubleshooting unattended EC2 UserData errors.
Long answer: you can run the UserData on each boot of the machine using Mime multi-part file. A mime multi-part file allows your script to override how frequently user data is run in the cloud-init package.
https://aws.amazon.com/premiumsupport/knowledge-center/execute-user-data-ec2/
For all those who will run into this problem, first of all check the log with the command:
sudo cat /var/log/cloud-init-output.log
then if you notice connection errors to the various repositories, the reason is because you don't have an internet connection. However, if once inside your EC2 you manage to launch the update and install commands, then the reason why they fail in the UserData is because your EC2 takes a few seconds to get the Internet connection and executes the commands before having it. So to solve this problem, just add this command after #!/bin/bash
#!/bin/bash
until ping -c1 8.8.8.8 &>/dev/null; do :; done
sudo yum update -y
...
This will prevent your EC2 from executing commands before an internet connection is established
I followed instructions at https://wso2.com/integration/install/docker/get-started/. When I try to access
https://localhost:9743/dashboard
as indicated, I get confronted right away with the HTTPS issue in edge, chrome and firefox. After entering login and password (admin, admin), I get a dialogbox as follows
I click on the link I get unable to connect in all browsers
I downloaded the pem certificate in Firefox, added it to trusted store but it did not help
Not sure what is needed to be done
You need to start the MI docker container as follows where it exposes port 9164.
docker run -it -p 8253:8253 -p 8290:8290 -p 9164:9164 docker.wso2.com/wso2mi:1.2.0
Then you can start the MI Dashboard container as below.
docker run -it -p 9743:9743 wso2/wso2mi-dashboard:1.2.0
When you are logging from the MI dashboard server, it calls the MI instance to authenticate the user.
I have some GCP users with the roles :
* compute.instances.osAdminLogin
* iam.serviceAccountUser
They connect throw ssh with the GCP web interface in compute engine
When they do sudo ls
For some user the password is requested and some not.
in the folder /var/google-sudoers.d/
for the users that can do sudo without the prompt we can read on their file:
user_name ALL=(ALL) NOPASSWD: ALL
for the others the files are empty
os information :
uname -a
Linux xxx 4.15.0-1027-gcp #28~16.04.1-Ubuntu SMP Fri Jan 18 10:10:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
For the same users, on another vm, in the same gcp project, they all can do sudo.
I am expecting that for all users having the same roles, they have the same sudo behaviour on instances.
What should I do for my users to be able to sudo ? ( except overriding the empty files in the folder /var/google-sudoers.d/ > that is working but may not be stable)
I had a similar problem on a project that was originally set up with the legacy login system (based on SSH keys stored in instance or project metadata). When I converted the project to use OS Login, I lost the ability to sudo without a password on one VM instance. This was a major problem, since I had never set a password for my user account, and therefore was unable to sudo to troubleshoot the problem.
Things I tried that did NOT work:
Rebooting the instance
Explicitly adding role roles/compute.osAdminLogin to my IAM account (I was already a project owner)
I solved the problem by editing the project compute engine metadata to disable OS Login. After disabling, I confirmed that I was able to log into the problematic instance and sudo without a password. I then edited the project metadata again to re-enable OS Login. This time, passwordless sudo worked on the problematic instance. It appears that the instance was not fully reconfigured the first time I switched from legacy login to OS Login.
I have a Django app running on a Linux server under NGINX. The "user" for the Django app is www-data. In this app, I try to connect to AWS IOT, and to do that I believe that the AWS boto3 package tries to find the AWS credentials here: ~/.aws/credentials. The problem is that for the user www-data there is no such path! When I login to the server (using my real username), and I try to run a script that connects to AWS, it connects just fine. Let's say my username is "joe". There is indeed a file /home/joe/.aws/credentials that contains the correct credentials. This is why the script works fine when I run as user "joe". But when the Django app is running, it doesn't work because there is no login user www-data, ie there is no file /home/www-data/.aws/credentials.
I understand that AWS boto3 let's us set an environment variable to specify a non-standard path to the credentials file. This env variable is AWS_SHARED_CREDENTIALS_FILE and there is also a AWS_CONFIG_FILE.
However, I don't know how to set an environment variable in Django for user www-data so that boto3 can now use that environment variable to specify the AWS credentials path.
Anyone know how to do this? Note that this is a production environment so I can't use any local server tricks/hacks.
If you are running your Django App from an EC2 instances the best practice is associate an IAM Role to the instance.
I had exactly the same issue but in a docker container and with apache instead of NGINX. For the container, we can do the following:
Edit /etc/apache2/envvars where environment settings for apache live:
echo "export AWS_SHARED_CREDENTIALS_FILE=/root/.aws/credentials" >> /etc/apache2/envvars
change ownership of aws credentials file parent directory:
chown -R www-data:www-data /root
restart
apache:
service apache2 restart
Note that here ownership of root's home directory was changed. This is because aws needs certain file permissions and ownership for the credentials file (which means only www-data will be able to use this login from now on.) Maybe it would be a better practice (especially if you're runnning on an actual machine and not a container) to copy the credentials file to a new location and follow the same steps:
mkdir -p /home/joe/workdir/.aws/
cp /home/joe/.aws/credentials /home/joe/foo/.aws/credentials
sudo chown -R www-data:www-data home/joe/foo/
sudo echo "export AWS_SHARED_CREDENTIALS_FILE=/home/joe/foo/.aws/credentials" >> /etc/apache2/envvars
sudo service apache2 restart
I don't know how well this fits to the NGINX config, but hope this helps a bit.
I installed the latest Google Cloud Deep Learning VM Image today, after VM was launched, I was able to do sudo -i successfully via SSH web.
Once I login, I start my Tensorflow model training running in background (Using &). Few hours later I'm unable to login as root.
I get the following message:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for my_username:
I tried:
sudo -i
su sudo -i
su root
I was able to replicate the issue. Any suggestions?
This issue was caused due to an internal Google side and removes the user from “Google-sudoers” group. For all affected instances, I suggest following the below workaround until the permanent fix has been rolled out.
Use a different username:
If using browser SSH window, click on the settings icon (top right), and click change Linux name in the drop down.
Using the SDK
$ gcloud compute ssh newusername#instance
Enable OS Login on the instance (set "enable-oslogin=True" in metadata) and per this article
You can track the permanent fix by following the Public Issue tracker.
The original answer:
Maybe the solution will be to add a SSH Key for Google Cloud Console and log in with another SSH client.
Additional answer:
I do not know why, but sometime the user suddenly stopped being a member of the google-sudoers group...
Then it's enough add your user to this group by some other user with administrator privileges to this group:
# usermod -G google-sudoers your_user_name
of course, if there is such a user...