When we start a Spring Boot server, there is always a startup message similar to the following:
Starting MyServerApplication on xxx with PID 1234
In this case, from where the value xxx is extracted? And how can I change it?
I ask this question because this xxx refers to an old app name that was later changed. However, I cannot find such a value anywhere in the code. That old name is not in any Java class, in any packages, in any xml or other configuration file known to me. I can't even find it by searching with a command similar to the following:
egrep -ir --include=* "xxx" .
Obviously xxx is just an example. My question applies to any other name logged at Spring Boot starting.
The xxx is the hostname of the machine where the application is running. To change the name, you'll need to change the hostname in the OS files. In Linux,
you can use sudo nano /etc/hostname to change the hostname of your machine and restart the machine.
Hope this helps.
Related
I'm wondering how I would go about creating my own bash script to ssh to a server. I know it's lazy, but I would ideally want not to have to type out:
ssh username#server
And just have my own two letter command instead (i.e. no file extension, and executable from any directory).
Any help would be much appreciated. If it helps with specifying file paths etc, I am using Mac OS X.
You can set configs for ssh in file ~/.ssh/config:
Host dev
HostName mydom.example.com
User myname
Then, just type
$> ssh dev
And you're done. Also, you can add your public key to the file ~/.ssh/authorized_keys so you won't get prompted for your password every time you want to connect via ssh.
Use an alias.
For example: alias sv='ssh user#hostname', then you can simply type sv.
Be sure to put a copy of the aliases in your profile, otherwise they will disappear at the end of your session.
you could create an alias like this:
alias ss="ssh username#server" and write it into your .bash_profile. ".bash_profile" is a hidden file is located in your home directory. If .bash_profile doesn't exist yet (check by typing ls -a in your home directory), you can create it yourself.
The bash_profile file will be read and executed every time you open a new shell.
You can use ssh-argv0 to avoid typing ssh.
To do this, you need to create a link to ssh-argv0 with the name of the host you want to connect, including the user if needed. Then you can execute that link, and ssh will connect you to the host of the link name.
Example
Setup the link:
ln -s /usr/bin/ssh-argv0 ~/bin/my-server
/usr/bin/ssh-argv0 is the path of ssh-argv0 on my system, yours could be different, check with which ssh-argv0
I have put it in ~/bin/ to be able to execute it from any directory (in OS X you may need to add ~/bin/ manually to your path on .bash_profile)
my-server is the name of my server, and if needed to set the user, it would be user#my-server
Execute it:
my-server
Even more
You can also combine this with mogeb answer to configure your server connection, so that you can call it with a shorter name, and avoid to include the user even if it is different than on the local system.
Host serv
HostName my-server
User my-user
Port 22
then set a link to ssh-argv0 with the name serv, and connect to it with
serv
* QUICK SOLUTION *
For those of you visiting this page based on the title solely and not wanting to read through everything below, or thinking everything below doesn't apply to your situation, maybe this will help... If all you are looking to do is change a users password on boot and are using Ubuntu 12.04 or similar, here is all you have to do. Add a script to start on boot containing the following:
printf "New Password\nRepeat Password\n" | passwd user
Keep in mind, this must be run as root, otherwise you will need to provide the original password like so:
printf "Original Password\nNew Password\nRepeat Password\n" | passwd user
* START ORIGINAL QUESTION *
I have a first boot script that sets up a VM by doing some configuration and file copies from a mounted iso. Basically the following happens:
VM boots for the first time.
/etc/rc.local is used to mount a CD ISO to /media/cdrom and execute /media/cdrom/boot.sh
The boot.sh file does some basic configuration, copies some files from CD to the VM and should update the users password, using the current password.
This part of the script fails. The password is not updating. I have tried the following:
VAR="1234test6789"
echo -e "DEFAULT\n$VAR\n$VAR" | passwd user
Basically the default VM is setup with a user (for example jack) with a default password (DEFAULT) The script above, using the default password updates to the new password stored in VAR. The script works by itself when logged in, but I cant get it to do the same on boot. I'm sure there is some sort of system policy or something that prevents this. If so, I need some sort of work around. This VM is being mass deployed and is packaged automatically and configured with a custom user password that is passed from the CD ISO.
Please help. Thank you!
* UPDATE *
Oh, and I'm using Ubuntu 12.04
* UPDATE *
I tried your suggestion. The following files directly in the rc.local ie the password does not update. The script is running however. I tested by adding the touch line.
touch /home/jack/test
VAR="1234test5678"
printf "P#ssw0rd\n$VAR\n$VAR" | passwd jack
P#ssw0rd is the example default VM password.
Jack is the example username.
* UPDATE *
Ok, we think the issue may be tied to rc.local. So rc.local is called really early on before run levels and may be causing the issue.
* UPDATE *
Well, potentially good news. The password seems to be updating now, but its updating to something other than what I set in $VAR. I think it might be adding something to it. This is ofcourse just a guess. Everytime I run the test, immediately after the script runs at boot I can no longer login with the username it was trying to update. I know that's not a lot of information to go on, but it's all I've got at the moment. Any ideas what or why its appending something else to the password?
* SOLUTION *
So there were several small problems as to why I could not get the suggestion below working. I won't outline them here as they are irrelevant. The ultimate solution was from Graeme tied in with some other features of my script which I will share below.
The default VM boots
rc.local does the following:
if [ -f /etc/program/tmp ]; then
mount -t iso9660 -o ro /dev/cdrom /media/cdrom
cd /media/cdrom
./boot.sh
fi
(The tmp file is there just to prevent the first boot script from running more than once. After boot.sh runs one, it removes that tmp file.)
boot.sh on the CDROM runs (with root privileges)
boot.sh copies files from the CDROM to /etc/program
boot.sh also updates the users password with the following:
VAR="DEFAULT"
cp config "/etc/program/config"
printf "$VAR\n$VAR\n" | passwd user
rm -rf /etc/program/tmp
(VAR is changed by another part of the server that is connected to our OVA deployment solution. Basically the user gets a customized, well random password for their VM so similar users cannot access each others VMs)
There is still some testing to be done, but I am reasonably satisfied that this issue is resolved. 95%
Edit - updated for not entering the original password
The sh version of echo does not have the -e option, unlike bash. Switch echo for printf. Also the rc.local script will have root privileges, so it won't prompt for the original password. Using that will cause the command to fail since 'DEFAULT' will be taken as the new password and the confirm will fail. This should work:
VAR="1234test6789"
printf "$VAR\n$VAR\n" | passwd user
Ubuntu uses dash at boot time, which is a drop in replacement for sh and is much more lightweight that bash. echo -e is a common bashism which doesn't work elsewhere.
i'm trying to run 3 node Hadoop cluster on Windows Azure cloud. I've gone through configuration, and test launch. Everything look fine, however, as i used to use OpedJDK which is not recommended as VM for Hadoop according to what i read, i decide to replace it with Oracle Server JVM. Removed old installation of java with Yum, along with all java folders in /usr/lib, installed most recent version of Oracle JVM, updated PATH and JAVA_HOME variables; however, now on launch i getting following masseges:
sed: -e expression #1, char 6: unknown option to `s'
64-Bit: ssh: Could not resolve hostname 64-Bit: Name or service not known
HotSpot(TM): ssh: Could not resolve hostname HotSpot(TM): Name or service not known
Server: ssh: Could not resolve hostname Server: Name or service not known
VM: ssh: Could not resolve hostname VM: Name or service not known
e.t.c. (in total about 20-30 strings with words which should not have anything in common with hostnames)
For me it looks like it's trying to pass part of code as Hostname because of incorrect usage of sed in start up script:
if [ "$HADOOP_SLAVE_NAMES" != '' ] ; then
SLAVE_NAMES=$HADOOP_SLAVE_NAMES
else
SLAVE_FILE=${HADOOP_SLAVES:-${HADOOP_CONF_DIR}/slaves}
SLAVE_NAMES=$(cat "$SLAVE_FILE" | sed 's/#.*$//;/^$/d')
fi
# start the daemons
for slave in $SLAVE_NAMES ; do
ssh $HADOOP_SSH_OPTS $slave $"${#// /\\ }" \
2>&1 | sed "s/^/$slave: /" &
if [ "$HADOOP_SLAVE_SLEEP" != "" ]; then
sleep $HADOOP_SLAVE_SLEEP
fi
done
Which looks unchanged, so the question is: how change of JVM could affect sed? And how can i fix it?
So i found an answer to this question: My guess was wrong, and everything with sed is fine. Problem however was in how Oracle JVM works with external libraries compare to OpenJDK. It did throw exception where script was not expecting it, and it ruin whole sed input.
You can fix it by adding following system variables:
HADOOP_COMMON_LIB_NATIVE_DIR which should point to /lib/native folder of your Hadoop installation and add -Djava.library.path=/opt/hadoop/lib to whatever options you already have in HADOOP_OPTS variable (notice that /opt/hadoop is my installation folder, you might need to change it in order for stuff to work properly).
I personally add export commands to hadoop-env.sh script, but adding it to .bash file or start-all.sh should work as well.
I've been trying to figure out how to use postfix on my Mac and something has gone horribly wrong and I can't seem to fix it.
I believe the problem is related to starting Postfix.
Basically, the Mac seems to refuse to change its hostname. In bash, the user appears as "admin#(null)", if I type 'hostname' I'm given "(null)" also.
Changing the hostname in Sharing from System Preferences causes the second example to change (where it says, for example, "Other users can access shared folders on this computer, and administrators all volumes, at afp://null/ or “lion2”.") but the first stays as null.
I've even tried /etc/hostconfig manually setting hostname but nothing works.
Is there somewhere else the hostname is trying to be set but is perhaps corrupt? Or contains an invalid character or something?
This is causing Postfix not to work and report:
postfix: warning: valid_hostname: invalid character 40(decimal): (null)
postfix: fatal: unable to use my own hostname
Please, I really hope someone can help me fix this. I've been trying for hours now.
Cheers,
Scott
Have you tried scutil?
sudo scutil --get pref will show the current value and sudo scutil --set pref name will set the value to name. pref can be one of these:
ComputerName The user-friendly name for the system.
LocalHostName The local (Bonjour) host name.
HostName The name associated with hostname(1) and gethostname(3).
Here's what I get on my machine:
$ sudo scutil --get ComputerName
SteveBook2
$ sudo scutil --get LocalHostName
SteveBook2
$ sudo scutil --get HostName
HostName: not set
You should have tried running /bin/hostname directly to set the hostname on the unix/bsd layer, the values from scutil are SystemConfiguration settings which is a higher layer that unix is oblivious to.
It is perfectly normal for sudo scutil --get HostName to return not set even if running /bin/hostname shows you a hostname.
To set the hostname run sudo hostname Foo.bar (this is basically identical to sethostname() BSD call in the code given by another answer)
Optionally you could then run sudo scutil --set HostName Foo.bar to keep the SystemConfiguration settings in sync
NOTE:
The HostName in SystemConfiguration can be different from the LocalHostName and ComputerName , it can also be different from what /bin/hostname returns but it is best that they are all in sync, so you could also do :
sudo scutil --set LocalHostName Foo
sudo scutil --set ComputerName Foo
All other answers and help was much appreciated, however after much investigation, the problem appears to lie with my router and iMac: router not allowing the iMac to change its hostname client-side OR possibly sending a weird hostname to the iMac for it to use.
If you run this tiny program before starting postfix, does it work?
#include <unistd.h>
int main(int argc, char* argv[]) {
char host[] = "newhostname";
sethostname(host, sizeof(host));
return 0;
}
I don't presume to know what else might depend upon your old hostname -- do some testing on all your services after running this.
Details at: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/gethostname.3.html
Update
To compile and run this little program, save its contents to a file (/tmp/newhostname.c will do) then run:
cd /tmp
make newhostname
sudo ./newhostname
At least I assume your make(1) knows how to compile from C sources to runnable binaries with default rules.
If the compiler isn't already installed maybe someone else will have a better idea.
I'm running a couple of standard Fedora instances on EC2. I feel the public hostnames of the instances assigned by Amazon are too weird and hard to remember. I'd like to change them to something short (like red/blue/green/etc).
Is there any draw back in doing this? And how do I set it up such that it persists after reboots?
Thanks.
Before you get started, try running hostname and hostname --fqdn and take note of what the responses are.
You can edit /etc/hostname and set a hostname, which will stick around after rebooting. You can force the hostname to be "reloaded" by using hostname -F /etc/hostname to read that value into the hostname. The bash prompt will change after you logout and login.
warning / note:
Yes, it is nice to have the hostname in the bash prompt set to something more useful than ip-123-123-123-123 but I've decided to leave mine (at least for now) because it seems like a lot of things really count on having the hostname on ec2 instances set in a standard way. After editing /etc/hostname and changing the hostname to webserver a lot of the services seems to fail because the hostname would not resolve, and apache wouldn't start. Next I edited /etc/hosts and added in
127.0.0.1 webserver
as the second line. Apache would then start but complained that it couldn't find the FQDN. I confirmed that running hostname --fqdn no longer worked.
Next I consulted man hostname and learned that while you can set the hostname it appears that the FQDN is what is returned via a DNS lookup.
THE FQDN
You can't change the FQDN (as returned by hostname --fqdn) or the DNS domain name (as returned by dnsdomainname) with this command. The FQDN of the system is the name that the resolver(3) returns for the host name.
Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.
Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.
I think it might be possible to set the system / fool the system into return the FQDN, something like ip-123-123-123-123.ec2.internal even though the hostname is webserver but at this point it started to seem like more trouble than it was worth, and that for me to have a nicer bash prompt might cause a lot software and configuration problems down the road and so I decided to give up.
I also learned that a lot of amazon ec2 instances use something called cloud-init:
cloud-init is the Ubuntu package that handles early initialization of a cloud instance. It is installed in the Ubuntu Cloud Images and also in the official Ubuntu images available on EC2.
Some of the things it configures are:
setting a default locale
setting hostname
generate ssh private keys
adding ssh keys to user's .ssh/authorized_keys so they can log in
setting up ephemeral mount points
cloud-init's behavior can be configured via user-data. User-data can be given by the user at instance launch time. This is done via the --user-data or --user-data-file argument to ec2-run-instances
I also found this which talks about how the hostname is configured with cloud-init:
On EBS instances, a shutdown and later start would end up with a different IP address.
In the case where the user has not modified /etc/hostname from its original value (seeded by metadata's 'local-hostname'), then cloud-init will again set the hostname and update /etc/hostname.
In the case where the user has modified /etc/hostname, it will remain user managed.
Additionally, if /etc/cloud/cloud.cfg contains 'preserve_hostname' value set to a True value, then /etc/hostname will not ever be touched.
The interesting takeaway is that if you don't change the hostname the cloud-init package will keep it up to date for you.
If someone else has a workaround or can address some of the issues mentioned and help reassure that nothing will break on ec2 instances because of changing the hostname I would be happy to hear it.
Another way is to simply edit ~/.bashrc and prepend PS1 with the nickname of the machine.
Edit: perhaps more correctly, machine-wide, e.g. on the AWS Linux AMI (an example) (paste this into console or add to your arbitrary install .sh):
cat << EOF | sudo tee /etc/profile.d/ps1.sh
if [ "$PS1" ]; then
PS1="[\u#myinst1:\l \t \! \W]\\$ "
fi
EOF
Edit /etc/sysconfig/network as root.
Replace
HOSTNAME=localhost.localdomain
with
HOSTNAME=hostname.DOMAIN_NAME
Then, either reboot or run /etc/init.d/network restart
The server then should report its name as a FQDN.
From this site:
Change the hostname on a running system
On any Linux system you can change its hostname with the command hostname (surprised?)…
Here are some quick usages of the command line hostname:
$> hostname
without any parameter it will output the current hostname of the system.
$> hostname --fqd
it will output the fully qualified domain name (or FQDN) of the system.
$> hostname NEW_NAME
will set the hostname of the system to NEW_NAME.
You can also edit /etc/hostname (at least on Ubuntu).
To make sure it stays after a reboot in AWS, either add the command in /etc/rc.local so it runs when the machine starts.
There's also a way to set the hostname dynamically via USER_DATA:
USER_DATA=`/usr/bin/curl -s http://169.254.169.254/latest/user-data`
HOSTNAME=`echo $USER_DATA`
IPV4=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/public-ipv4`
hostname $HOSTNAME
echo $HOSTNAME > /etc/hostname
To change the system hostname to a public DNS name
Follow this procedure if you already have a public DNS name registered
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the fully qualified domain name (such as webserver.mydomain.com).
HOSTNAME=webserver.mydomain.com
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.mydomain.com
To change the system hostname without a public DNS name
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the desired system hostname (such as webserver).
HOSTNAME=webserver.localdomain
Open the /etc/hosts file in your favorite text editor and add an entry beginning with 127.0.1.1 (on DHCP systems) or eth0's address (on static IP systems) to match the example below, substituting your own hostname. (127.0.0.1 should be left as the localhost line.)
127.0.0.1 localhost localhost.localdomain
127.0.1.1 webserver.example.com webserver
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.localdomain
Note: You can also change the shell prompt without affecting the hostname. Refer to this AWS documentation.
Sure, you can do that if you have your own domain (setup a CNAME to point to the Amazon hostname). Otherwise, you're pretty much stuck with the one they give you (or an Elastic IP, if you set one of those up).
The /etc/rc.local solution worked for me for a basic hostname but does not give me a FQDN.
In my Linux AMI (a snapshot of other instance).. none of the above formula worked. Then, I simply changed HOSTNAME field in file: /etc/init.d/modifyhostname and did a normal reboot.
You will need to do multiple things to set the hostname:
hostname newname - sets the hostname, but is volatile
edit /etc/hostname - sets the hostname for the next reboot
edit /etc/hosts - to keep sudo from complaining
I put these together into a script and uploaded it as a gist:
https://gist.github.com/mnebuerquo/5443532036af8b48995547e2817dba85
sudo hostname *yourdesiredhostnamehere*
sudo /etc/init.d/networking restart
then the hostname is changed. On my server all other services like apache and postfix works. Server is Ubuntu 12.04 LTS