So that's how they came up with that. As someone who normally installs "normal" Linux systems I find it quite irritating that you have to put a file somewhere, especially the boot record, to "enable" ssh of all things. Up until now I considered it a weird decision. (and I still think it is not optimal) I deploy my RPi's in the field and don't put a monitor on them so I would expect ssh running as default. First time I found out about it was when reading the unit file when I was building a custom image based on raspbian, so I wouldn't consider it obvious :) When working on a Linux Device I just mount the main partition and do my customizations.
Probably the right decision then. As I don't put them on public networks and delete the pi user this is of little concern to me, but given the target group, it is a simple safety measure.
This is how it works in ARMbian. It forces a password change on first login. It can be annoying if you intend on deleting the alarm user right after that, but I can easily see why. "Default" passwords are always suboptimal.
> I deploy my RPi's in the field and don't put a monitor on them so I would expect ssh running as default. First time I found out about it was when reading the unit file...
So I guess you weren't building those images? If you're building headless RPi images that's something you learn immediately.
I have a tendency to learn stuff in reverse. I used to make an SD Card ready, connected monitor and keyboard and enabled everything as needed. Then I got the task to deploy n-RPi's and looked at the image first to customize it for the requirements we had. That's when I looked around and saw the unusual unit file and tried to understand why the service would look at the boot partition to start a service. In the end I think I added the symlink to start the service thorugh systemd.
I don’t know the details of how they implement this but it sounds like you want a systemd drop in file to override the ConditionPathExists (or similar) directive (I’m assuming you can’t or don’t want to modify the upstream unit directly given the use of symlinks).
Or you can chroot to the mounted Raspbian root partition and do a normal `systemctl enable ssh` as part of your image customisation. Because, to be clear, you do not have to put a file in /boot to enable SSH, as it was claimed above. That is purely a helpful shortcut.
I'm interested in trying it. In the past I used a system based on Debian's Live Build (https://github.com/gumstix/live-build) and I was wondering how it differs, but I'm just now noticing even this suggests using Yocto instead.
Really interesting read for me. I am currently not so far from your SSD point but our setup still works fine most of the time. It’s just 100k/m though. I am trying to use more of the Go implementations of the graphite stack which did improve load. I will consider m3db probably to get some benchmarks. All the other ones would require some more people as you said.
Do you mean Utrecht and Arnhem or those on the German side? Or are you talking about using regional trains? I feel like the worst thing about the route is the lack of High Speed Lines but on the other hand these regions are densly populated so it does make sense to stop at some places.
Can you tell me which tool you consider for getting netflows? I am trying building something that is really close to what you describe but fail to find the time to do so.
Where are you located? I just wonder if this is because the enviroment isn't firendly to normal bikes either. Where I live I don't have any issues to park a bike. And I would never take it on a bus/train because there is no such thing as last mile when biking, especially ebiking.
Sunrise at 7am seems fine to me. But at my place for example it would mean sunrise as late as 9 or 10am at the shortest day of the year. This is compelling to me at least.
