Arm development topics/issues

Still working on the NS-arm 7.5.1804 and running in to some topics/issues I’d like to discus

EPEL arm-32bit
We talked about the status of the unofficial epel for arm-32bit before; but as stated getting the mirror of this nice and clean is time consuming and quite honest not a pleasant task to do.
My proposition is we work on a alpha release which researches directly in to the unofficial epel,
for the last RC we build up the mirror and if all is well we go to final. This would speed up development and getting test images out.

Simple wifi (WPA-Supliant) module.
Need help for a for a Simple wifi (WPA-Supliant) module. I can make some action scripts around wpa-cli to set a wifi connection up. However if we wat something in http-admin i miss the php skills. @denis.robel You did some work on hostapd, could this be a better route than wpa-cli?

Would pushing some arm specific patches “upstream” x64_86 be accepted?:

(small stuff)
Base Dashboard Hardware info
Most arm devices we are targeting now do not have a bios, they are device-tree based. hence /sys/devices/virtual/dmi/ is not present. A rather small patch from @dz00te would clean it up enough.

Mock
Just one if elif else and adding two configuration files would do the job.
Not important rather a small frustration of me: building on relatively slow hardware, I want to propose to keep the chroot between building he sRPM and the RPM. This would speed up a lot! Keep in mind the builddir is the chroot is cleaned-up by mock even if you opt for --no-clean, it just keeps the chroot…

(bigger stuff)
Nethserver-base
Disable local AD option for arm-32bit maybe 64-bit. Did not thought about how to do this, it would imply greying out a button is arch = arm.

Dropping smartmontools dependency for nethserver-base
(Again) Most arm devices we are targeting don’t have SMART-enabled diskdrives…
Dropping dependency for nethserver-base implies moving all smartmonitor parts from nethserver-base to nethserver-smartd. nethserver-smartd is a mysterious package, it just holds the default-db part of the service. Why? And could we shift parts (if there are any) from base to smartd?

grtz mark

@dz00te @denis.robel @m.traeumner @

6 Likes

No problem at all but the code should be platform dependent. I think we can simply find a condition for it.

I think we can merge it as is, would you mind to open a PR?

I think this could be conditional too. Am I right @davidep?

Maybe we can also try to create some Travis jobs (Support Android / Arm · Issue #3376 · travis-ci/travis-ci · GitHub) ?

We can do it, then add back the package inside nethserver-iso yum group.

I think there is no real configuration apart for the record to enable the daemon.
Could you please point me to other smartd stuff inside nethserver-base?

Thanx for the answers, you can expect some new “isues” on the bug tracker with PR’s the comming days

well I could not find any… Hopped you knew :grinning:
Did not look in to it much, now there is an principle of acceptance, I will look in to it in more detail.

Would be great, looked for a arm build node and did not find it… As I have little understanding of this travis-cli infrastructure didn’t put much time in it, also because i never looked in to docker…:roll_eyes: (just use nspawn if i need a container)

So, this confirms we can safely remove the dependency from nethserver-base :+1:

Mark, could you please open all PRs including the one to nethserver-base?
After that, I will create a recap issue where all PRs will be linked togheter

2 Likes

PR’s are in the making, working on them i found this code scrip-let in FirstConfigWiz/RootPassword.php of nethserver-base:

/**
 *  show this page only if the root user has still the default password:
 *  @return mixed The integer position, or NULL if this page must be hidden
 */
public function getWizardPosition() {
    return $this->user->getCredential('hasDefaultPassword') === TRUE ? self::WIZARD_POSITION : NULL;
}

how can we get this to pop up on the first boot of a nethserver-arm image? i.e when is ‘hasDefaultPassword’ TRUE?

When the user logs in the typed password is compared with the default one Nethesis,1234 and the result is recorded.

:+1: Nethesis,1234 is going to be the new default-password!

1 Like

As discussed in this post i’d like to push some arm-specific patches to “upstream” x86_64.

It did not make sense to do this as-long it is in a “devel” state by now the basic modules proved to be stable and can be regarded being in a beta-state maybe even RC1.

Holding me back is the infrastructure: one patch, nethsever-mock, includes the repositories for arm.
I am very happy (having full rights/control) with the development repository provided by @mrmarkuz. :+1:

From another point of view it’s not so good: it would be better if the maintenance / development can be done / shared by a group of people. This implies more people have rights to manage the repositories.
Moreover it’s about time we start to (re)sign the packages.

How do we proceed?

To get the discussion going some options / ideas:

  • Push stable parts to repo provided by @dz00te
  • Provide stable repo on infrastructure provided by @mrmarkuz
  • Can nethsever / nethesis set-up an DNS record / forward requests?
    (It would not mater where the repo “moves” to in the future… )
  • Host repositories on infrastructure provided by nethsever/nethesis
  • Signing packages: which key ?

More ideas?

cc// @davidep @giacomo @alefattorini

2 Likes

I’m personally favorable to add the arm architecture to packages.nethserver.org repositories, which already provides authentication and automated RPM signing.

3 Likes

Sounds good to me!
What do have in mind? An altarch branch like centos does? CentOS Mirror

for armhfp (32 bit) we have two out of the ordinary repositories:

  • a partial mirror of the unsigned “epel”.
    This mirror is kept update manually with a simple (= unforgiving) script.
  • a mirror of the community effort for SCL-PHP72.

How to deal with those two?

@mark_nl have you seen this post?
https://blog.centos.org/2018/09/epel-for-armhfp/
so at the same time we can test ns7arm and help Pablo :wink:

2 Likes

No I did not, Good news!

Tried to leave a comment without success, will do so on the mailing list.
Tried to give feedback in the past without getting a response. Kind of gave up on it, maybe it changes with a new face.

1 Like

BTW @dz00te can I ask you to comment on / review the patches planned to propose?

Don’t hold back :grinning:

1 Like

Me too.

Maybe we will need to refine the ACLs, but it could work.

the 2nd line of /proc/cpuinfo on my Cubieboard2 running Fedora 29-beta is:

model name : ARMv7 Processor rev 4 (v7l)

Is that useful?

# ls /sys/devices/virtual/dmi/id/
ls: cannot access '/sys/devices/virtual/dmi/id/': No such file or directory

ls /sys/firmware/devicetree/base/ 
'#address-cells'   cpus               model           soc@1c00000     vcc3v0
 ahci-5v           display-engine     name            thermal-zones   vcc3v3
 aliases           hdmi-connector     pmu             timer           vcc5v0
 chosen            interrupt-parent   psci            usb0-vbus
 clocks            leds               serial-number   usb1-vbus
 compatible        memory            '#size-cells'    usb2-vbus

Mailing list???

where is there information about your mailing list(s) and the archives?

or email me the info at rgm at htt-consult dot com

thanks

Hi Robert,

Welcome and nice you have interest in the project we are running here.

Well, you kind of looking at it, this forum is the equivalent of a mail list;
if you have questions: go ahead.

I agree the SOC (ie Allwinner A20, Broadcom BCM2837) would be nicer. unfortunately can not find a entry in /proc or /sys universal for all boards. Opted for this because the information is at least technical sound : ARMv7 Processor rev 4 is the cpu of the SOC. If you happen to know a better option please let us know.

On systems without a bios, this includes all devicetree based systems, this directory is not present. Hence the proposal to look in /sys/firmware/devicetree too if no dmi information is present.

I’d be interested in the content of /sys/firmware/devicetree/base/model of the Cubieboard2. Proposal is to show this on the dashboard @ hardware info. (thanx in advance)

1 Like

Greetings. I turned on email in my profile and let’s see how responding to the email works…

I have been at it since Fedora first did an image for the Cubieboad. I just happen to have Fedora 29-beta up and running on a test unit:

# cat /sys/firmware/devicetree/base/model
Cubietech Cubieboard2 

Come to think of it, Medon has Centos7 code and shows the same thing. More later when I power up my Cubietruck

hmmm, discovered a problem using email replies. Seems to be a limit to how many replies to a person? And how many messages per day for new members? anyway, here it is…

I have a Linkspire Nano sitting in my board box. I can put an image on it and see what is in …/model if that would help.

Now on to some of my thoughts:

Start with the gnome image, not the minimal. You get all the WPA supplicate support and a lot more. Follow my instructions to get vncserver working so you save overhead on your server. It would be interesting if we could get a reverse vnc install for headless installs.

I would MUCH rather have Xfce, but for some reason the arm repos do not have a Xfce DE group. I tried to put one together, but I lack the skills to get it right, plus some obvious modules were missing. If someone could take this on, we would have a good GUI via vnc. If you follow Fedora user and testing lists, you will see the fun and games I had getting Xfce and vncserver to play together. I have submitted 2 bug reports on what I learned.

What size partitions does the standard Nethserver build? I don’t like what is in the Centos image and use gparted to get what I want. Not easy to ‘automate’. I have been burned by /boot being too small. And I like a larger swap. So what I have to do is first move the / partition over. Then I enlarge and move swap. Next I enlarge /boot. Finally I enlarge /. I do it this step-wise way as I had problems trying to do them all in one instruction to gparted. But do you want any special partitions for stuff?

The beauty of the Cubieboards (and a few other) is native sata. All I put on the uSD card is uboot. If your board does not have sata, try putting the image on your usb HD and only uboot on the uSD card. It MAY work. Problem may come if there are 2 usb drives connected.

What about RAID? I do have a multiport sata card here, but I was not able to get it to work. Anyone interested in trying it?

Back to WiFi and hostap. Again with the Gnome image, at least on Cubietruck, there is working WiFi without a dongle. I will see about installing hostap soon. the nmcli is also available. I have done a lot with it for just the ethernet setup (see my web page). There is a lot of information on it for configuring WiFi.

For Samba support, I SHOULD be happy with PDC and roaming profiles. And Windows7 support (my wife’s system).

X.509 certificates. I will see what you have done, but I have 2 Internet Drafts on using command line openSSL to produce usable PKIs. See my github for this work. The certificates are ECDSA and EDDSA (requires the brand new v 1.1.1). Less CPU use needed for these algorithms over RSA and we should at least use ECDSA on arm servers. EDDSA wide support is probably a year out.

Meanwhile while waiting to post this I did my first install and I will create a post on my notes.

More to follow…