YunoHost 3.4 release / Sortie de YunoHost 3.4

Announcements
, ,
22

Oui, mais à quoi est-ce que tu penses par exemple ?

N.B. : en étant admin, tu peux facilement passer root avec 'sudo su'

1 Like
23

Je pensais aux logs des mails, par exemple, ou php. :slight_smile:

24

Minor version 3.4.2.3 was released and should fix the following :

  • Admin password appearing in logs when login in from the webadmin
  • Updated the IP for DNS resolvers according to diyisp.org
1 Like
25

I was on yunohost “beta” to try 3.4, now that it is out, how can I switch back to stable?

26

You should already be in 3.4.2.x (the stable release) but if you want to avoid upgrading to the next testing, you can edit the repo config using nano /etc/apt/sources.list.d/yunohost.list

then replace ‘testing’ by ‘stable’, save, and do an apt update (it never hurts)

1 Like
27

Hello, the upgrade worked well, globally, except for one package : onlyoffice (not stable at this time I know).
I think there is a problem with nginx conf files and headers. But I don’t if the pb is linked to Yunohost or specific to the package.
Here the error I have :
La ressource à l’adresse « https://cloud.monsite.com/yunohost/sso/?r=aHR0cHM6Ly9jbG91ZC5oYW5uZWJlcnQuY29tL3luaHBhbmVsLmpz » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).

I reported it on github : https://github.com/YunoHost-Apps/onlyoffice_ynh/issues/6#issuecomment-462032427

I would appreciate any help :slight_smile:

28

Hmmokay, I’m not sure but it could be related to a change in the nginx header (add_header -> more_set_headers) but one would need to investigate deeper to really understand what’s going on :s

29

I could try in deleting the added header in nginx conf files for nextcloud domain and/or onlyoffice domain. Is it dangerous ?

30

Thanks!

1 Like
32

Soooo pre-installed images for ARM boards were upated !

https://yunohost.org/#/images

They should be working well and everything (been checking RPi and orangepi PC+), but it wouldnt hurt if some people could validate them on their side as well.

In particular, I’m interested if someone could test the RPi image on an HDMI screen to see if the whole initial bootprompt thing really does work nicely now. (It has only been tested in a virtualbox)

34

J’ai ce problème pour l’accès SFTP a mes webapp également…

37

Salut !

Je n’ai lancé la migration SSH que aujourd’hui, petit retour d’expérience :slight_smile:

Etat des lieux avant la migration

  • j’utilisais une authentification SSH par clé sur un port my_ssh_port différent du port 22 (qui était bloqué), j’avais suivi le tuto YunoHost • index
  • Je me connectais avec un utilisateur my_ssh_user qui n’était ni admin ni root.
  • La connexion SSH par mot de passe était interdite sur le serveur (PasswordAuthentication no dans /etc/ssh/sshd_config).
  • Pour me connecter j’utilisais une commande de la forme :
    ssh -i ~/.ssh/id_rsa -o IdentitiesOnly=yes -p my_ssh_port my_ssh_user@IP

→ Lancement de la migration

Après la migration

  • impossible de me connecter en SSH : le port 22 était fermé … heureusement yunohost-api était démarré donc ouverture du port via l’interface admin web
  • application de la procédure de @Gofannon ici : Ssh auth via private/public key impossible - #4 by Gofannon (section Connexion au serveur en forçant l’utilisation du mot de passe au lieu de la clef ssh) pour copier le .ssh/authorized_keys de l’utilisateur my_ssh_user vers admin
  • réappliquer la procédure YunoHost • index pour rechanger le port de connexion de 22 à my_ssh_port, et bloquer le port 22
  • reforcer la connexion par clé en ajoutant PasswordAuthentication no dans /etc/ssh/sshd_config

Pour finir petit conseil utile : pensez à ouvrir le port 22 avant de lancer la migration et démarrer le service yunohost-api pour conserver un accès admin au cas où …

Merci @Aleks et @Gofannon :slight_smile: