Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade issues due to my server setup #21

Open
ErikDeBruijn opened this issue Oct 4, 2014 · 0 comments
Open

Upgrade issues due to my server setup #21

ErikDeBruijn opened this issue Oct 4, 2014 · 0 comments

Comments

@ErikDeBruijn
Copy link
Contributor

The instructions at raptorFollowupInstructions.txt are really good, as long as your setup is not like mine. I've been trying to upgrade the e-nable hand-o-matic over at e-nable.youmagine.com and it generates files, but my e-mail setup was different. I'm using postfix on this ubuntu system and it does come with the mail command, but it's apparently not entirely compatible with the usage in the shell scripts that get executed:

mail  -a 'Content-type: text/html' -a 'CC:[email protected]' -a 'From: e-NABLE' -s 'e-NABLE Model' [email protected] < /var/code/Service-Station/ticket/2663516195-1015839576-3980356043/README.html

This returns just Content-type: text/html: No such file or directory in my case. This error was hard to find, I could get it by finding the shell script and executing that line myself. This is no objection to the code written!

I ended up fixing my setup by seeing what mailclient binary actually was used.

root@enable1:/var/www/html# sudo update-alternatives --display mailx
mailx - auto mode
  link currently points to /usr/bin/heirloom-mailx
/usr/bin/heirloom-mailx - priority 60
  slave Mail: /usr/bin/heirloom-mailx
  slave Mail.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
  slave mail: /usr/bin/heirloom-mailx
  slave mail.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
  slave mailx.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
/usr/bin/mail.mailutils - priority 30
  slave mail: /usr/bin/mail.mailutils
  slave mail.1.gz: /usr/share/man/man1/mail.mailutils.1.gz
  slave mailx.1.gz: /usr/share/man/man1/mail.mailutils.1.gz
Current 'best' version is '/usr/bin/heirloom-mailx'.

This was changed by the command sudo update-alternatives --config mailx

There are 2 choices for the alternative mailx (providing /usr/bin/mailx).

  Selection    Path                     Priority   Status
------------------------------------------------------------
* 0            /usr/bin/heirloom-mailx   60        auto mode
  1            /usr/bin/heirloom-mailx   60        manual mode
  2            /usr/bin/mail.mailutils   30        manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/mail.mailutils to provide /usr/bin/mailx (mailx) in manual mode

I have a few suggestions though, it would help if:

  • the errors that result from the shell script would be visible. Possibly we just need to add 2>&1 to where it gets executed to allow stderr tot also reach the logs.
  • the use of heirloom-mailx is discouraged explicitly in the install documentation.
  • the zip file was downloadable from the final page without having to look for an e-mail. The service.php script is a great interface to have a checker running that will tell the user about the "in progress" and "done" states and if there's a link, no reason not to display it too, right? E-mail adds a dependency on the setup, as you see in my case that's a problem. I've no problem with changing my setup, but I wanted to get this working with minmal changes to the host.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant