Editing 1654: Universal Install Script
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 20: | Line 20: | ||
One of the more subtle jokes in the comic is the inclusion of <code>apt-get</code> and <code>sudo apt-get</code> in the same script. Good unix practice dictates never logging in as root; instead you stay logged in as your normal user, and run system admin accounts via <code>sudo program name</code>. This prevents accidental errors and enables logging of all sensitive commands. A side effect of this, however, is that an administrator may forget to prefix their command with <code>sudo</code>, and re-running it properly the second time. This is a common joke in the Linux community, an example of which can be found at this [https://web.archive.org/web/20220304210306/https://twitter.com/liamosaur/status/506975850596536320 viral tweet] which shows a humorous workaround for the issue. | One of the more subtle jokes in the comic is the inclusion of <code>apt-get</code> and <code>sudo apt-get</code> in the same script. Good unix practice dictates never logging in as root; instead you stay logged in as your normal user, and run system admin accounts via <code>sudo program name</code>. This prevents accidental errors and enables logging of all sensitive commands. A side effect of this, however, is that an administrator may forget to prefix their command with <code>sudo</code>, and re-running it properly the second time. This is a common joke in the Linux community, an example of which can be found at this [https://web.archive.org/web/20220304210306/https://twitter.com/liamosaur/status/506975850596536320 viral tweet] which shows a humorous workaround for the issue. | ||
β | Since Randall's script does not use sudo for any but the <code>apt-get</code> command, there are two possibilities: the script itself was run via the root user or via sudo, in which case the <code>sudo apt-get</code> is not needed, or the script was run as a normal user, in | + | Since Randall's script does not use sudo for any but the <code>apt-get</code> command, there are two possibilities: the script itself was run via the root user or via sudo, in which case the <code>sudo apt-get</code> is not needed, or the script was run as a normal user, in which case all of the commands will fail (due to lacking necessary permissions) with the possible exception of the <code>sudo apt-get</code> one. |
Sudo has also been used both by [[Randall]] in [[149: Sandwich]] and by Jason Fox to force Randall to let him appear on xkcd with [[824: Guest Week: Bill Amend (FoxTrot)]]. | Sudo has also been used both by [[Randall]] in [[149: Sandwich]] and by Jason Fox to force Randall to let him appear on xkcd with [[824: Guest Week: Bill Amend (FoxTrot)]]. | ||
Line 26: | Line 26: | ||
The tool <code>curl</code> downloads files from the network (e.g., the Internet). For example, <code>curl http://xkcd.com/</code> downloads and displays the xkcd HTML source. The pipe <code>|</code> in the script attaches the output of the command before the pipe to the input of the command after the pipe, thus running whatever commands exist in the web content. Although this "curl|sh" pattern is a common practice for conveniently installing software, it is considered extremely unwise; you are running untrusted code without validation, there may be a MITM who modifies the code you receive, or the remote system could have been hijacked and the code made malicious. Most local package managers (e.g. <code>apt</code>, <code>yum</code>) offer digitally-signed packages that thwart this problem. You can find many examples of software providers suggesting a <code>curl|sh</code> solution at [https://curlpipesh.tumblr.com/ curlpipesh] | The tool <code>curl</code> downloads files from the network (e.g., the Internet). For example, <code>curl http://xkcd.com/</code> downloads and displays the xkcd HTML source. The pipe <code>|</code> in the script attaches the output of the command before the pipe to the input of the command after the pipe, thus running whatever commands exist in the web content. Although this "curl|sh" pattern is a common practice for conveniently installing software, it is considered extremely unwise; you are running untrusted code without validation, there may be a MITM who modifies the code you receive, or the remote system could have been hijacked and the code made malicious. Most local package managers (e.g. <code>apt</code>, <code>yum</code>) offer digitally-signed packages that thwart this problem. You can find many examples of software providers suggesting a <code>curl|sh</code> solution at [https://curlpipesh.tumblr.com/ curlpipesh] | ||
β | There appears to be a bug with the & at the end of the "git clone" line; since a git repository typically contains program source code, not executables, it may have been intended to retrieve the source code with git and then compile and install the program in the next line. In this case, the single & should be replaced with &&, an operator that will run the second command only if the first one has completed successfully. This plays into a second bug on the "configure" line, where the placement of the & means that only the "make install" command will be run asynchronously after the "configure" and "make" steps have finished in sequence | + | There appears to be a bug with the & at the end of the "git clone" line; since a git repository typically contains program source code, not executables, it may have been intended to retrieve the source code with git and then compile and install the program in the next line. In this case, the single & should be replaced with &&, an operator that will run the second command only if the first one has completed successfully. This plays into a second bug on the "configure" line, where the placement of the & means that only the "make install" command will be run asynchronously after the "configure" and "make" steps have finished in sequence. To make success as likely as possible, the two lines should be like this or script should be executed twice: |
β | git clone <nowiki>https://github.com/</nowiki>"$1"/"$1" && (cd "$1"; ./configure; make; | + | git clone <nowiki>https://github.com/</nowiki>"$1"/"$1" && (cd "$1"; ./configure; make; make install) & |
Since all commands are running in the background, any command that requires user input will stop and wait until brought to the foreground. A common request would be for a database password, or if it is allowed to restart services for the installation. This could lead to packages being only partly installed or configured. (See more about using "yes" below.) | Since all commands are running in the background, any command that requires user input will stop and wait until brought to the foreground. A common request would be for a database password, or if it is allowed to restart services for the installation. This could lead to packages being only partly installed or configured. (See more about using "yes" below.) |