Should unattended openhabian install create user?

Setup, Configuration and Use Installation
Tags: #<Tag:0x00007efec29b5998>
#1
  • Platform information:
    • Hardware: Raspberry Pi 4 8GB
    • OS: Ubuntu 20.04.1 LTS
    • Java Runtime Environment: OpenJDK Runtime Environment (Zulu 8.48.3.246-CA-linux_aarch64) (build 1.8.0_265-b11)
    • openHAB version: 2.5.x
  • Issue of the topic: Unattended installation description could be more detailed

I am running Ubuntu from a USB stick on a raspberry pi 4 with 8Gb.
I opened the openhabian documentation page and followed the steps detailed there.

After running openhabian-config unattended I assumed the username provided in /etc/openhabian.conf would have been created. Bu that is not the case (and no errors shown about it)…

Is my assumption wrong?

#2

Yes. Probably. Well. I should know but I do not because that code has been untouched in a very long time.
Clearly Ubuntu/USB boot is a strange combo on Pi that we don’t support so don’t test in development.

Either way - why the heck do you run Ubuntu on a RPi when there’s the openHABian image ?
Use the alpha image for your 8GB model.

1 Like
#3

Because

  • the openHABian release notes state ‘64bit version (for testing only, DO NOT USE IN PRODUCTION)’

  • one doesn’t want to run alpha software

  • one wants to use USB boot and read your reply here. Note that this reply was made after the release of the openHABian alpha release you are now recommending to use.

  • one doesn’t like design choices made for the openHABian distribution

  • one wants to use a distribution created by a company who’s core business is providing a Linux distribution and not an SBC for schools to tinker with

  • one want’s to run more than just openHAB

  • Ubuntu 20.04 LTS is supported for the next 5 years

just to name a few.

Seriously, why do you always need to question peoples motives when they run something different than openHABian?

2 Likes
#4

I think Marcel makes valid points but moreso: I am using what it says in the documentation and it appears the documentation is not clear about this (all other items in the config file likehostname, timezone. locale etc are indeed set or created, but not username password).

So assume I am running DriesOS on UnsupportedHW, my question still applies.

Next to that: it is not that clear that ubuntu for ARM is unsupported
" openHABian is also supposed to run on generic Debian/Ubuntu based systems on x86 and some ARM hardware platforms. Start with a fresh installation of your operating system, login and run"

#5

Because very often their motives are just lack of knowledge (e.g. here that there is an image you can run the 8GB RPi4 from).

Because quite some requests make supporters and contributors victim to the XY problem like in #8 of
How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community.

Because I want to learn about what we might consider to become features in future development.

We put a hell lot of our spare time into making things work. That is only feasible if you restrict yourself to a number of prerequisites such as choice of HW and OS.

If you don’t like it you don’t have to use it.

It is disrespectful and to me not acceptable to ask volunteers to do exactly those pieces of work we are trying to avoid (such as to find out why it does not work on your specific preferred combo) although we have stated in the README and on many more occasions that we cannot afford spending that much time or don’t have the HW available or whatever reason - the bottom line is that’s disrespectful.

Seriously, why are you
- who has not contributed anything to openHABian and who is not even the OP to have a problem -
so disrespectful against volunteers spending their spare time to provide you with a free tool that is of benefit to many people ?
This is the second time in a fortnight you do this for no apparent let alone acceptable reason.

cc: @ndye @Benjy

#6

Im sorry to say, but you have a strange way of showing this “interest”. I often ser you telling people what not to do, rather than trying to put yourself into their decision, from their point of view. Specially regarding wether openhab should support funktions like USB boot from the Rpi, your latest comment I saw was, that it is not going to happen for the openhabian hasslefree installation. Thats not an interest. Thats your opinion only and your dictate.

3 Likes
#7

Then the answer (to the question from the title) is “no” or precisely, like in terms of a formal spec, behavior is undefined in this case. That’s in line with my response, isn’t it?

The support statement is in the README. Let me know what is unclear about that.

Your quote is from openhabian.md and only states “is supposed to run on”, and if you read on it says

Please note that we cannot test HW/OS combos upfront so there is no support / no guarantee for this work as explained in the [README](../README.md).
Don't be too disappointed if you run into errors. Drop us a note on Github.
#8

The code is on Github, everyone’s free to use and modify for himself so yes my opinion but barely a “dictate”. Or do you think others like yourself should be allowed to define what I need to work on ?

An - to say the least - interesting statement from another non-contributor at the voluntary main contributor.

#9

Call me stupid, but I don’t see how that is an answer to my question.

Talk about being disrespectful…

C’mon, don’t start spreading fake news :wink: I already contributed to openHAB 1.x in 2015.

1 Like
#10

@dries_dokter
Sorry for derailing your topic, that was not my intention.

To answer your question:

The following snippet is from the helpers.bash script and determines if the hardware is a pi.

is_pifour() {
  if [[ "$hw" == "pi4" ]]; then return 0; fi
  grep -q "^Revision\\s*:\\s*[ 123][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]11[0-9a-fA-F]$" /proc/cpuinfo
  return $?
}
is_pi() {
  if is_pizero || is_pizerow || is_pione || is_cmone || is_pitwo || is_pithree || is_cmthree || is_pithreeplus || is_cmthreeplus || is_pifour; then return 0; fi
  return 1
}

Because you are running on a pi, the is_pi() method will return true. However, the user that is logged into your pi when running the first-boot.bash script is probably not pi so the renaming of the user pi to openhabian is skipped.

Whether this is a bug or a design decision I don’t know.

userdef="openhabian"
if is_pi; then
  userdef="pi"
fi

echo -n "$(timestamp) [openHABian] Changing default username and password... "
# shellcheck disable=SC2154
if [[ -z "${username+x}" ]] || ! id $userdef &> /dev/null || id "$username" &> /dev/null; then
  echo "SKIPPED"
else
  usermod -l "$username" "$userdef"
  usermod -m -d "/home/$username" "$username"
  groupmod -n "$username" "$userdef"
  chpasswd <<< "$username:${userpw:-$username}"
  echo "OK"
fi
1 Like
#11

This also does not work with a fresh PI OS Full 32bit installation (Buster; released 2020-08-20 with latest updates).
“openhabian-config unattended” does not create the openhabian user.

If you install interactively instead (manual installation in openhabian-config), the openhabian user is created and installation succeeds.

1 Like
#12

No. And that wasn´t the question here. Dont twist this.
You said, “I want to learn about…”.
I stated, your interest is quite strange, cause mainly, you do not see things from other people side of view. I gave you the example with the USB booting, which at bottom line is all about what you believe. Even though several users have said they would like to use USB boot. You simply refuse to listen to them because you dont have a need and dont see the need.
Next thing, you tell tem to either accept, or “create” it themselves.

Excuse me, but thats not an “I want to learn” attitude, in my opinon.

What exactly does it require to become a “contributer” in your opinion?
A user who help another user in the community, dont he contribute anything? (simple yes/no answer).
A user who help testing snapshot/new release, dont he contribute anything? (simple yes/no answer).
A user who participate in debates about openhab developement, dont he contribute anything? (simple yes/no answer).

As you may have figured by now - contribution, in my opinion, is not just a question of providing codes/scripts/maintaining. There are lots of ways to contribute. But you dont seem to acknowlegde them in any way!

#13

We see all points of view, however we must make calculated decisions about what to spend our time on in order to insure a well rounded and stable openHABian experience. Simply because a few users want USB boot does not mean that the developers will instantly spend their time on implementing it, the developers have other interests and major concerns about the project, as such we collectively made a decision, not just @mstormi, that it was not going to be a focus of our project. This decision was made primarily because the current recommended way to install any Raspberry Pi OS image (or flavor thereof) is to use an SD card and flash the image to it. Furthermore, the developers of openHABian don’t have the time to invest in USB boot as an alternative method of installing, as that would draw away from their concerns and ongoing projects to improve openHABian.

A contributor in the sense that @mstormi used it means a direct contributor to the inner workings of the openHABian. There is a lot of discussion about what is to be worked on that goes on behind the scenes for openHABian, we decide from many requests which are the most important and would have the longest lasting value for the end users.

All of your questions are able to be answered as ‘yes’, but it is the particular way that one contributes that @mstormi was referring to, the developers of openHABian spend a lot of our free time on this project and we cannot and will not be able to support all of these requests that we get. We do our best and give everything consideration however, some things must be rejected as we have to maintain the project in addition to adding new features and that is a full time project in and of itself. Therefore, yes opinions will be present in the choices we make about the project but we do our best to be fair in those judgments. All of the developers have input on the features of openHABian if they choose to give it @mstormi is not the only deciding factor. This is a volunteer project and as such those who volunteer more of their time for it, accordingly have more say in the functionality that is included.

I will leave you with that, I hope that we can avoid any further bickering and stay productive. We are not trying to be rude, but we have priorities and they are not all the same as yours and discussions like this only distract and waste our time.

2 Likes
#14

This whole discussion, that I did not ask for, leaves me a bit reluctant to still reply but I will anyway. First of all I waited with this reply so I could think about it a little. I sometime need a step back, for a more balanced :slight_smile: reaction

@mstormi your replies made me feel attacked more than they made me feel helped. And as you have stated: I should not feel entitled to your help but I hope you agree this forum is a place where one should feel safe to ask questions even if people need to disagree. It is not so much your opinion, it has to do with the delivery. You can of course ignore this observation, but as you are spending so much time building openHABian I assume building the community is also close to your heart.

It was mentioned that my motivation and my level of knowledge could help understand where I am coming from, so I will still try to provide it.

First of all I, being impressed by the performance of the Raspberry Pi 4 8Gb I decided I wanted to use it to offload some of the things I have currently running on my “home server” (firewall, fileserver, ftp, ldap and vpn server etc). In the past I moved openHABfrom that home server to a raspberry pi 3b (running openHABian)

Why USB:

  • It runs much faster than from SD card
  • One of the things I had in mind is to move e.g my nextcloud server to this pi

Why Ubuntu:

  • It appears that even the Raspberry Pi OS is still in beta, Ubuntu server for ARM 64Bit is not and support appears to be pretty solid.
  • I already had a USB bootable image
  • Before I switched to manjaro, ubuntu was my OS of choice, I am familiar with ubuntu
    (but also with raspbian, rhel and manjaro)
  • Many application can be found and installed directly from the supported repositories.
  • The openhab .debs are availble for ubuntu arm 64

I am not really happy with the performance of my current raspberry pi 3b , especially the response when a rule has not been triggered for a while (and is no longer in memory). So I thought to just try and see how the pi4 would handle openhab.

I could have just installed openhabian on the ubuntu Pi4 (I will probably do just that) but had a look at the documentation (on openhab/docs) and for openhabian there is a chapter “other linux systems” that provides no guarantees but also does not completely slam the door so I made a backup of my ubuntu Pi and just gave it a try.

So that brings me to:
Why openhabian:

  • Easy installation of frontail, mosquitto, influxdb+grafana etc
    I could do all this by myself but openhabian would make things easier.
  • If it would work why not :slight_smile:

So I know that openhabian was created with another intention but I can imagine that openHABian has value on any distribution. And although Ubuntu ARM 64 is not supported, it appears close to what is already supported. If it is worthwhile to consider this I of course leave up to you. I am more than happy to test this and share my experiences.

Sidenote:

In the openHABian documentation it says: “Please note that we cannot test HW/OS combos upfront so there is no support / no guarantee for this work as explained in the README.” I expect that that should have linked to the readme you mentioned, at the moment it does not.

#15

So I didn’t and so it does me.
Then again I admit it was more the others (who didn’t have any stake at all in this discussion but nonetheless joined) to upset me, in particular Marcel attacking me for no valid reason.
So one more reply to yours, then let’s end this please.

My apologies that that happened, it wasn’t my intention. Then again I believe the major part of that was a misinterpretation on your part. If it was in my words please let me know where exactly.

And please be aware it went both ways. Just for an experiment, try switching POV:
What would you think when you’ve put a lot of work into making a thing work for others, even explicitly documented the no-gos (and I guess I don’t have to mention everybody hates doing docworks), even explained the reasoning behind (support efforts you cannot provide) just for someone to come along, ignore the docs and prerequisites (and work put into) and ask right about that thing you stated you don’t want to do ?
Even after you gave a correct answer, even admitting in there you don’t know everything about the product you maintain.
I wouldn’t call that an outright appreciation of your work.

Yes that helps.
I regularly keep answering questions that later on turn out made me victim to the XY problem, and that means someone wasted my and others’ time because they were unwilling to write the full thing down in the beginning. Very ineffective communication that is, and very frustrating to volunteers willing to help.
That’s what the XY thing is about.

I don’t know when you looked but in the current version, it is linked.
And I hope you agree that that is no reason not to read the README. It was referenced. And doing so would have made it clear upfront that what you were going to request is unsupported.

#16

Ofocuse not. And it was never my intention to express anything like that.
I do understand and agree with priorities. They´re necessary for the developement.
But when there are priorities, an explanation becomes important, if you want the community to understand the priorities. If the explanation makes no sense or, what usually happens, those who ask for an explanation is beeing told, developers/maintainers dont have to explain their decisions. The priority become negative in itself.
I´m not saying you (or Markus) has to agree with me or anyone else. But its possible to listen, debate and communicating even while disagreeing. It´s called, respect for other people points of view!

#17

FWIW, this is unrelated to 64/32bit, and for the most part unrelated to HW … sure a RPi4 is a little faster and Java heap allocated by default is also more when you have more RAM. But HW does not make for a fundamental difference, you could also tune the JVM RAM settings instead (as the openHABian image does BTW).
64 bit IMHO has nothing but drawbacks. It’s theoretical advantages that don’t apply in an OH context.
It doesn’t hurt to read a README every now and then, sorry ;-).

#18

I was not happy with my Rpi3B+ either.
I bought an Rpi4 4GB, but I have to admit, I have been having several issues trying to get it running stable, wether I choose the official released openhabian images or beta/alpha versions (32/64bit) with SD card and/or USB (SSD).
The Rpi4 should have been way faster, but it´s not. Infact at some point, it seems quite slower.
I never actually got as far as to test my main system on this Rpi4, before I had to give it up and move everything to my Odroid C2 insted, which is running Ubuntu.

#19

I did read that, and I did tune my JVM Ram. It did help a little I. That together with “time triggered rules that keep the rules in memory” solved the immediate issue.
BTW: Ubuntu repositories do have a working ARM 64bit azul java

From the “official documentation page”: https://www.openhab.org/docs/installation/openhabian.html#other-linux-systems-add-openhabian-just-like-any-other-software even after a refresh, appears to be outdated then.

Yes, let’s do that :slight_smile:

#20

I might still decide to start and use the raspberry pi as a “docker server” and move openhab back to the fileserver (that is running RHEL) as that never gave any of these issues