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

add support for /boot/rc.local.txt if exists #207

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@sneak

sneak commented Sep 19, 2018

This adds a stanza to the raspbian rc.local that will source the contents of a /boot/rc.local.txt if one exists.

This allows for a Windows or macOS user to image with a stock raspbian image, then mount the boot partition which is vfat (supported well under Windows and macOS) and drop an rc.local.txt on it with their own local configuration, then install it into a pi and boot it. This allows for e.g. configuration of wifi or provisioning of SSH keys easily without requiring a keyboard/monitor. Otherwise, the user would have to grok the pi-gen repo and build their own custom image with their local configuration, or connect video/keyboard. Both are suboptimal.

If the user declines to drop an rc.local.txt file in the vfat boot partition, there is no change from default behavior.

sneak added some commits Sep 19, 2018

@sneak

This comment has been minimized.

sneak commented Oct 11, 2018

@XECDesign any chance of getting this merged?

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 11, 2018

Sorry, I know this feature is very much in demand, but not yet. I've been wanting to unify a bunch of options in a single file, rather than keep adding more files to /boot.

I'm hoping to pick this back up off the shelf again at some point:

#
#
#   Raspberry Pi headless configuration file
#
#   To use the settings in this file, you will have to uncomment and change
#   them. Settings which are commented out are left unchanged.
#
#

# ------------------------------------------------------------------------------
# Basic settings
# ------------------------------------------------------------------------------

# Hostname - the visible name for this Pi on a network
#
# hostname="raspberrypi"

# Change pi user's password
#
# pi_password="raspberry"

# Interfacing options
#
# ssh="off"
# vnc="off"

# Wireless settings
#
# wifi_ssid=""
# wifi_passphrase=""

# ------------------------------------------------------------------------------
# Advanced settings
# ------------------------------------------------------------------------------

# Static IP configuration
# Example:
# static_interface="eth0"
# ip_address="192.168.0.10/24"
# routers="192.168.0.1"
# domain_name_servers="192.168.0.1 8.8.8.8"
#
# static_interface=""
# ip_address=""
# routers=""
# domain_name_servers=""


# SSH settings
# The content of authorized_ssh_keys is appended to
# /home/pi/.ssh/authorized_keys. Line breaks are permitted.
# ssh_password_auth sets whether tunnelled clear text passwords are enabled.
#
# authorized_ssh_keys=""
# ssh_password_auth="on"

# Path to user-provided script
# run_script needs to be the full path to a script (for example, "/boot/run.sh")
#
# run_script=""

# Localisation options
# keymap sets the keyboard layout. For example, "us".
# List of available locale options can be found in /usr/share/i18n/SUPPORTED
# timezone data is a path relative to /usr/share/zoneinfo/. For example,
# "America/Los_Angeles".
#
# keymap="gb"
# locale="en_GB.UTF-8"
# timezone="UTC"
@sneak

This comment has been minimized.

sneak commented Oct 15, 2018

Until such time that happens, could we merge this in? Your solution might be better for newbies and should prove to be quite useful, but in the short term, this resolves the issue and is useful even in the case of the newbie-friendly solution (as it doesn't look like your ini file wishes to support arbitrary command execution, and this allows someone to use a standard shell script). This doesn't add any more files to /boot unless the user wants to.

EDIT: oh, I missed the run_script option - but even then that requires two files added to boot, the configuration file and the script to be run. If we support an rc.local.txt then it adds zero files to boot unless the user wants to use a rc.local.txt.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 15, 2018

It's very tempting to click merge, but past experience warns me against that. It won't go over well in the long run.

It's hard to remove things after they've been added. News of this new feature will spread, some will come to rely on it and then get stung when it's replaced. I'd like to avoid half-measures and the noise it would generate.

rc.local is one of the first walls beginners hit, it's far from user-friendly. It actually requires pretty good knowledge of linux to do things right in rc.local and when you do have enough knowledge you realise that you should write a service instead of using rc.local. The most common mistake people make is being unaware of the environment rc.local runs in (as root, without all the typical environment variables set) and wonder why their commands work from the terminal, but not in rc.local. They also tend to brick their setup by running applications which don't exit, so they never get to a log-in shell. There are just too many pitfalls that I see time and time again. They'll end up pasting random scripts they find on the forum which may or may not do the right thing and when things break, they'll say Raspbian is unstable. The feature would get abused and we would be blamed.

Yes. run_script has some of the same problems, but it will run as a service and have a warning that it's for advanced users and is not supported. It would be harder to get into a situation you can't recover from. Yes, it's two files, but it's JUST two files, as opposed to ssh, wpa_supplicant.conf, rc.local.txt and whatever else has been suggested since ssh has been added.

@sneak

This comment has been minimized.

sneak commented Oct 16, 2018

News of this new feature will spread, some will come to rely on it and then get stung when it's replaced.

So don't replace it, leave it in when you add a simpler, newbie friendly system. There is no maintenance cost to supporting this feature.

They also tend to brick their setup by running applications which don't exit, so they never get to a log-in shell

Yes, we are all aware that running things as root can brick your system. These same users have a root login shell, your arguments are invalid because they can all be applied equally to "cut and pasting things from the internet". There is no more risk to the Raspbian project's reputation by letting people exec commands from a file than letting people exec them from a root shell. Letting users execute commands they put in a file is not abusing the feature, it's working as intended. Lowering the barrier to letting users run commands from a windows-accessible or osx-accessible FAT partition does not suddenly put the project at risk because most users have no idea what they're doing; all you're doing is adding additional and unnecessary steps for people who do know what they're doing to get work done. Those same idiot users who would use an rc.local.txt that they don't understand and blame Raspbian are the same users who will paste things they don't understand into a root shell and blame Raspbian. It will just take them slightly longer to do so.

This rejection of a very simple, common-sense UX improvement is the second (other is #213) in a very short period of time. It is clear you are more interested in writing long-winded rejections on sketchy, edge-case grounds than accepting help to make the project more useful to people actually using it, so I've decided to maintain my own fork instead, as my efforts trying to simply extend and uncontroversially improve your efforts are being consistently rejected.

http://rachelbythebay.com/w/2018/10/09/moat/

Best of luck to you and your project. Good luck with the paternalistic ext4 gatekeeping.

@sneak sneak closed this Oct 16, 2018

@sneak

This comment has been minimized.

sneak commented Oct 16, 2018

A reminder: one of the most important lessons that one learns, early on, when using Linux, is that the computer will actually do precisely what you tell it to do, without regard for what you may have meant for it to do.

I'm not suggesting we burden newbies with useless troubleshooting busywork, but this change did not change any default behavior, it simply gave another avenue for customization. Those that expressly choose to customize would need to learn the above lesson sooner or later, just as we all did.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 16, 2018

Good luck to you too (genuinely).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment