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

Cant find newly installed Raspberry Pi OS (2023-10-10) in headless mode #50

Open
mats-nk opened this issue Oct 12, 2023 · 13 comments
Open

Comments

@mats-nk
Copy link

mats-nk commented Oct 12, 2023

Describe the bug

I found that a freshly installed image created with imager has lost the support for mDNS (avahi), workstation.

The impact is that it was previously easy to find a headless installation without hassling with scanning or checking routers DHCP leases.

Please change this back to the previous behavior.

File affected: /etc/avahi/avahi-daemon.conf

Change needed, from publish-workstation=no to publish-workstation=yes

Steps to reproduce the behaviour

Install sudo apt avahi-utils

Browse mDNS, avahi-browse -a and no "workstation" can be found.

Enable it and restart avahi service and it can be discovered, see bug report for details.

Device (s)

Raspberry Pi Zero W / WH, Raspberry Pi Zero 2 W, Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B, Raspberry Pi 400

System

System Information

Raspberry Pi 3 Model B Plus Rev 1.3
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"

Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 962bf483c8f326405794827cce8c0313fd5880a8, stage2

Logs

No response

Additional context

No response

@pelwell pelwell transferred this issue from raspberrypi/linux Oct 12, 2023
@lurch
Copy link
Collaborator

lurch commented Oct 12, 2023

ping yourhostname.local still seems to work fine (which I believe is what most people will be using), so I guess this is similar to raspberrypi/rpi-imager#655 where it's looking for a specific "advertised service", rather than just the hostname.

@ghollingworth
Copy link
Contributor

I guess this has come from upstream: Titled: "Don't leak host info by default"

avahi/avahi@530fbb5

@XECDesign
Copy link

Do we want to do anything about that? It seems like a sensible upstream change, especially if we couple it with the proposed change Andrew linked.

@mats-nk
Copy link
Author

mats-nk commented Oct 13, 2023

Before disregarding this I would like to ask "What is the goal what Raspberry Pi OS"?

As I understand it, it is broadly used as a first step into Linux and the Linux foundation has made a wonderful job in that aspect.

As for myself I am actively assisting new users to get started with Linux, and as I have been working with Linux servers since 1999 I have seen that to get a system up and running the first time is hard.

So to skip this is a blow back for the "Lite OS" and headless installation usability and I propose to investigate a bit further what the implication would be for the project.

And as for security concerns, "security by obscurity" is bad security policy in my world.

And lastly if Andrew is lurch, then it is my feature request he linked to ;-)

@ghollingworth
Copy link
Contributor

I understand, but if the upstream developers have made a change to a package configuration we shouldn't just go reversing it without any thought to the consequences. I know there are usability ones that you point out, but I don't know if there are security concerns as well that we don't know about. For example, what if this is a commonly used path for some known hacking software and that is why they changed it?

That's why I want to understand it, if you want to get in touch with those developers to make sure they don't know of any 'known attack vectors' that would really help

@ghollingworth
Copy link
Contributor

As an example the following was found two days ago:

avahi/avahi#485

I'm unsure how relevant this is, but would prefer getting some feedback before reenabling this...

@mats-nk
Copy link
Author

mats-nk commented Oct 13, 2023

I agree, to understand what you do and what the implications is, is important. I am all in for not taking quick decisions.

@mats-nk
Copy link
Author

mats-nk commented Oct 13, 2023

I would like to propose a workaround/solution.

If a "First boot script" feature could be introduced, ex /boot/1boot.sh. The idea would be that this script is run when the Raspberry Pi OS has completed its first boot completely.

The benefits would be huge for the Raspberry Pi community.

@lurch
Copy link
Collaborator

lurch commented Oct 13, 2023

If a "First boot script" feature could be introduced

See the discussions in raspberrypi/rpi-imager#174 and RPi-Distro/raspberrypi-sys-mods#40 and raspberrypi/rpi-imager#554 etc.

@mats-nk
Copy link
Author

mats-nk commented Oct 13, 2023

And should I understand it that the door is closed for this feature?

@ghollingworth
Copy link
Contributor

The concept of running some extra script may be added to Imager in a later revision. But it is not going to be available in the next one

@mats-nk
Copy link
Author

mats-nk commented Oct 17, 2023

Ok, thx for the answer. But kind of the same answer when I proposed it in 2016.

@lurch
Copy link
Collaborator

lurch commented Oct 17, 2023

It's probably something that we don't officially support, but if you want to hack this in yourself, see #72 (comment)

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

4 participants