2

I have been trying to automatically install postfix in a non-interactive way via startup-script on machine boot up.

After a bit of research I found out some suggestion that I could try to install it manually on a sample machine using desired configurations then obtain the right answers regarding configurations when startup-script will be running by using

debconf-utils package command debconf-get-selections | grep postfix >preseed.cfg

The problem is with one configuration which is the mailname that is due to the fact that my instance machines are generated in a non predetermined manner by the gcp cloud host I can not tell in advance which name to pass as I initially pass the first config selection as:

debconf-set-selections <<< 'postfix postfix/main_mail_type string "Local only" 

Now the question is how could just leave the default value? (which one could see had it been an attended installation and simply click ok to finish up)

  • The $HOSTNAME environment variable should give the hostname of the machine ... while hostname -f should give you the FQDN of the machine. The mail server hostname could be pre-pended to the the FQDN ... – RubberStamp Nov 6 '18 at 17:26
0

Thank you Kusalananda! I guess now I understand where the bug is. Before this bug came up I did try to use some expect script and spawn bash subscript within it as a way to indirectly install postifiX interactively via ready made expect-send question and answer pair series. I later decided to change this plan and removed the expect script altogether and turned to DEBIAN_FRONTEND="noninteractive" with debconf-set-selections command. Now the problem as I learned from some posts on this site was obviously due to calling the modified remains of this bash subscript with su command(as you may know that postfix installation supposedly should run with root privilages) within the main startup-script as every time it ran it threw exception upon calling this subscript with message 'ERROR OPENNING TERMINAL: UKNOWN' . After I reviewed some posts in here I found out that I could solve that by modifying the subscript code introducing some code as illustrated below

UID=$(ID -U)
if [xUID != x0]
then 
printf -v cmd_str '%q'"$0" "$@" 
exec su -c "$cmd_str"
fi
#the rest of the script code
#continues hereunder

After I made changes to the subscript; removing its declaration, its activating chmod, its call via commenting deleting its #!/bin/bash line and including its functional parts procedural-wise to the main startup-script now the script is running as its supposedly should.

  • Thank you sebix for the text readerbility improvement – Benedict Nov 9 '18 at 5:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.