I tried to do the following:
Download: client EC2 in https://aws.amazon.com/developertools/351. And save that in C:/AWS/CLI.
Create in the environment variables, a new system variable.
Name: JAVA_HOME
Value: C:\Program Files\Java\jre7
Create other new system variable.
Name: EC2_HOME
Value: C:\AWS\CLI
Edit the value of the system variable Path, and add %EC2_HOME%\bin.
Create other two system variables:
System variable name: AWS_ACCESS_KEY, value: my access key.
System variable name: AWS_SECRET_KEY, value: my secret key.
Open my windows command line and execute the code:
ec2-stop-instances <id_instancia> –region <region>
I received the error:
the filename, directory name or volume label syntax is incorrect.
Why does this happen?
Those API tools look somewhat old.
These days, it is recommended to use either:
AWS Command-Line Interface (CLI) (Windows, Mac, Linux)
AWS Tools for Windows PowerShell (Windows only)
If you like PowerShell, use that one. Otherwise, go for the AWS CLI. There is good documentation for both.
There's an extremely easy way to stop the instance from the instance's cmd, that is
shutdown /s
That will shutdown (and stop, not terminate) the EC2
Related
Mac 10.14.6
iTerm2 Build 3.4.8
Google Cloud SDK 351.0.0
beta 2021.07.30
bq 2.0.70
core 2021.07.30
gsutil 4.66
Logging in to my virtual gcloud server without errors with:
gcloud compute ssh myserver
However, the backspace key in the terminal registers as a space key.
Tried exactly the same with the stock Mac terminal, the same behaviour.
What gives?
The backspace key will often seem to register as a space key if the environment variable TERM is not set to a value that is defined in your terminfo configuration.
You can check the value of TERM by running:
echo $TERM
terminfo can be configured in several places, but on Google Compute Engine it is likely using the values from /lib/terminfo. (Other possibilities include $HOME/.terminfo and /usr/share/terminfo.) You can check if your current setting for TERM corresponds to a file in this directory by running:
find /lib/terminfo -name $TERM
If the value is present, you will see something like /lib/terminfo/s/screen-256color. If it is not present, you will not see any output.
You can fix the problem by ensuring that your TERM environment variable is set to one of the files defined in terminfo.
This document says to set DATABASE_URL=postgres://$(whoami) this to maintain parity between local and pro dbs. But what should I replace "whoami" with?
I have installed PostGreSql on my machine. How to I perform CRUD operations?
That whoami will return username of the current user when invoked. As the documentation said, you just need to type the below in command prompt (no need to replace whoami), depends on your OS:
Linux / Mac:
export DATABASE_URL=postgres://$(whoami)
Windows:
set DATABASE_URL=postgres://$(whoami)
After set up Postgres, you can use psql client to access the database. As you asked in comment regarding how to run .sql file, here's the steps:
In command prompt, type "psql". You are now connected to your database.
Inside psql, type "\i your_sql_file.sql". This execute the your_sql_file.sql file.
We have a Windows EC2 instance on which we are running a custom command line application (C# console app using NpgSQL) to connect to a PostgreSQL RDS instance. Based on the instructions here:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.SSL
we created a new DB parameter group with rds.force_ssl set to 1 and rebooted our RDS instance. We also downloaded and imported to Windows the pem file referenced on the page.
I was able to connect to the RDS instance from my Windows EC2 instance via pgAdmin by specifying SSL mode as Verify-Full. Our command-line application reads connection strings from a file and they look like this now that I've added the sslmode parameter:
Server=OurInstanceAddress;Port=5432;SearchPath='$user,public,topology';Database=OurDatabase;User Id=username;Password=mypassword;sslmode=verify-full;
Using this connection string failed with the error referenced at the bottom of the page:
FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
I tried adding the sslrootcert parameter, but I'm not sure if I'm dealing with it properly. I tried using the example (sslrootcert=rds-ssl-ca-cert.pem) and I tried using the name of the pem that I downloaded. I feel like there is something about the path information that I'm giving to the sslrootcert parameter that isn't right, especially in a Windows environment. I've tried using the name, I've tried using the following paths:
- sslrootcert=C:\keys\rds-combined-ca-bundle.pem - single backslash
- sslrootcert=C:\\\keys\\\rds-combined-ca-bundle.pem - double backslash
- sslrootcert=C:/keys/rds-combined-ca-bundle.pem - Linux style backslash
All of these produced the same error mentioned above.
Any insight would be appreciated.
I solved it using the environment variables instead for specifiying cert paths in connection url
-DPGSSLROOTCERT=/certs/root.crt
-DPGSSLKEY=/certs/amazon-postgresql.key
-PGSSLCERT=/certs/amazon-postgresql.crt
Although I'm in cygwin. There are some hints in the documentation when using windows here https://www.postgresql.org/docs/9.0/static/libpq-ssl.html
I am starting the jboss_3.2.7 with the linux user jbs using jboss with RUNASIS option, but it is not working while the entire system[linux] restart. Which is starting the jboss as root user.
I added the jboss service in chkconfig option of linux for starting the jboss on linux restart.
In the jboss service file (/etc/init.d) modified the user to RUNASIS
define the user under which jboss will run, or use RUNASIS to run as the current user
JBOSSUS=${JBOSSUS:-"RUNASIS"}
You are using quite old JBoss version and I personally never see it. But I think it should be very similar to newer ones.
Please try to put your user after when defining these variable:
JBOSSUS=jbs
The other solution is to setting these variable before executing running script:
export JBOSSUS=jbs; /etc/init.d/jboss start
Update
I have just downloaded JBoss 3.2.7 and I checked the jboss_init_redhat.sh script (I hope you use these one as a templete for your starting script).
In the file jboss_init_redhat.sh you can find such lines:
#define the user under which jboss will run, or use RUNASIS
#to run as the current user
JBOSSUS=${JBOSSUS:-"jboss"}
These line defines the new user name. It checks if the variable JBOSSUS is set up and if not is uses jboss user as default name.
The second interesting part of these script:
if [ "$JBOSSUS" = "RUNASIS" ]; then
SUBIT=""
else
SUBIT="su - $JBOSSUS -c "
fi
You should know one thing: when you run automatically any script from init scripts it is always run as a root user. Thats why in the script should be command which change the effective user to someone else. And here you have these part of the script.
It first checked if your username is RUNASIS and if it is yes - do nothing. In another case it run JBoss as a another user by using su command.
In your case it should be sufficient to change JBOSSUS variable definition to something like that:
JBOSSUS=jbs
After that you can start these script as a root user and it should run JVM with JBoss with jbs user.
I'm using PostgreSQL DB in my application, I used to create special windows user account to run the DB service.
Now I need to run PostgreSQL service under Local System account! Is there a configuration in PostgreSQL to specify the user account which the service runs under?
Thanks,
Computer Management -> Services -> select the Postgres server service -> right click -> Properties -> check the Log on tab, just like any other Windows service.
(Might be a bit off with the naming, I don't have access to a Windows machine at home, but I'm sure you can improvise.)
Download the zip archived binaries from PostgreSQL site. Extract the contents. Create a folder, say 'data', for storing the db files etc. Open Windows Advanced System Configuration -> Environment Variables.
Create a new System Variable called PGDATA and set its value to the complete path of data folder, as in - 'C:\PostgreSQL\data'(without the single quotes).
Next in Path variable include the complete path to bin folder, as in - 'C:\PostgreSQL\bin;....' .
Once done, do the following...
Open command prompt(as Admin in Vista and Win 7 systems). Type: 'initdb' and press Enter. This will do the initial setup.
In the same command prompt window, type in: 'pg_ctl register -N PostgreSQL -U LocalSystem' and press enter.
Open run and type services.msc and check if the process 'PostgreSQL' has been created and that you can actually start it.
I don't believe that you need to do anything special to run this under a local system account. We use PostgreSQL databases here and we install them on local system accounts all the time. I have never seen a configuration setting in the installation that allows you to indicate a system account for the service.