LEDE v17.01.0-rc1

Linux

Az OpenWrt-ből forkolódott LEDE projekt bejelentette, hogy elérhető tesztelésre a "Reboot" kódnevű LEDE 17.01 stabil terjesztés első kiadásra jelölt verziója. Bejelentés itt, wikioldal itt. Image-ek letölthetők
https://downloads.lede-project.org/releases/17.01.0-rc1/">innen.

( kisg v | 2017. 02. 01., sze – 21:11 )

Nem az volt legutóbb a hír, hogy kibékültek az OpenWRT-vel?

Szerintem igen, ha nem a factory, hanem az upgrade image-et teszed fel. Azért nem volna baj, ha előbb a /etc-t összeraknád egy tar.gz-be, majd kimásolnád ssh-n a gépedre, biztos ami biztos alapon.

Bátorkodom megjegyezni, ha vannak saját csomagjaid, amelyeket telepíteni szeretnél, s nincs kedved minden frissítést követően ezzel szöszölni, jobban jársz, ha az image buildert töltöd le, csinálsz magadnak testre szabott image-et, majd ezt teszed a routerre. Én egyébként így csinálom. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem nekem is, nevezetesen TL-WR841ND. 4 MiB flash és 32 MiB RAM van benne. Snapshot-ot rakok rá. Azért nekem ez így megvan:

#!/bin/bash

make clean
make image PROFILE='tl-wr841-v10' PACKAGES='coreutils-base64 ddns-scripts etherwake mailsend-nossl nano shadow-su uhttpd -ppp -ppp-mod-pppoe' FILES=files/

Ami annyit tesz, hogy nincs ppp-m meg ppp-oe-m, ellenben van nano, ddns, továbbá etherwake, amellyel be tudom kapcsolni az otthoni gépemet a neten keresztül, bárhol vagyok is, ezen felül sima user joggal be tudok lépni, a root ssh-t tiltottam. Ezen felül saját scriptjeim vannak a /usr/local/bin-ben. Meg ssh publikus kulcs, így a saját gépemről ssh-nál nem kér jelszót.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem kényelmesebb. A vi-jal sincs baj insert módban, de ha véletlenül elfelejtek 'i'-t nyomni, akkor bosszús leszek.

Szerk.: ha meg többet kell szerkeszteni, áthozom a desktop gépre a file-t, szerkesztem mcedittel, aztán visszateszem a routerre.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem tudom, nekem abszolut kezre all a vi (es altalaban a kepernyot nezem gepeleskor, szoval ha verem a billentyuket es nem tortenik semmi, akkor vagy az i hianyzik vagy ki van huzodva a vezetek :)

Nincs rmate-hez hasonlo Linuxra? Igaz ehhez meg Ruby kell, de pont ilyen esetekre valo.

https://github.com/textmate/rmate

De, a terminal parametereivel van a gond (egyebkent 2xESC vagy CTRL+C mindig kivisz insert modbol) http://www.johnhawthorn.com/2012/09/vi-escape-delays/

Mac OS X-en az F-billentyuk alapvetoen nem funkciobillentyuk, ezert en pl. Midnight Commanderben is ESC+szambillentyu segitsegevel szoktam masolni, etc.

Értem én, csak azt nem, hogy
- a vim mindig jó
- a 20+ éves Solarios buta vi is mindig jó volt
- ha xtermből csinálom direktben, akkor a busybox vi is jó
- ha xterm+screenből csinálom, akkor a busybox vi nem jó - de a vim igen, a 20+ éves Solarisos buta vi is!

Szóval valaki magyarázza el, hogy pontosan melyik terminálnak milyen paramétere nem jó, ami pont így manifesztálódik (az alapproblémát értem, csak azt nem, hogy miért nem mindig egyformán szar).

Azert nem lehet erre egyszeruen valaszolni, mert meg kell nezni hogy melyik terminal kezeli rosszul a modifier key-eket. Alapvetoen akkor var az ESC utan, ha ugy gondolja hogy nincs META key a terminalon (pont azert var, hogy ESC+billentyuvel a META+billentyut tudd bevinni). Ez lehet a fizikai terminalod (a billentyuzeted), lehet a terminal emulatorod (xterm) vagy lehet a tuloldalon (mivel gondolom SSH-zol az eszkozre) emulalt terminal. FYI Mac OS X-en iTerm2-bol csont nelkul mukodik mind a busybox-os vi, mind pedig a debianos vim, nem var semennyit ESC utan.

Itt sem vár, ha natúr futtatom az xtermben. Viszont screennel együtt már nem jó - de csak a busybox, a vimnek így is jó! Az ssh nem oszt, nem szoroz, lokálban is pont ugyanaz a jelenség. A TERM sem befolyásolja, tehát eleve nem a terminfót használja - ha igaz, amit írsz, akkor valahogy inband kell megkérdeznie a termináltól, hogy van-e rajta Meta vagy sem... ami azért érdekes, mert azt nem tudhatja az xterm, hogy van-e egyáltalán olyan gomb a billentyűzeten, ami azt a keycode-ot generálja, amire a Meta mappelve van (mondjuk speciel van is).

- a vim-nek nincs ilyen problémája a screennel (most akkor a vim eleve nem is tartalmazza ugyanezt a "logikát", vagy nem a screenen múlik a dolog)
- export TERM=xterm után nem javul meg screenen belül, export TERM=screen után nem romlik el screenen kívül (ergó nem a terminfót használja a logika)

Bármelyik csomagot beleteheted így az image-be, amelyet opkg-vel tudnál telepíteni. A kérdés az, mennyi flash van a router-ben. Én például az mc-t erre a picike, 4 MiB flash-t tartalmazó routerre nem tudtam feltenni, mert a függőségeivel együtt ekkora flash-be nem fért el. Ezért tettem fel a nano-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

luciban van egy system/backup-flash-firmware/configuration menupont
ez az /etc/sysupgrade.conf -t irja amiben alapbol ez talalhato:

## This file contains files and directories that should
## be preserved during an upgrade.

# /etc/example.conf
# /etc/openvpn/

--
neked aztan fura humorod van...

Nem mondott szerintem hülyeséget. Egyrészt nem muszáj luci-t használni. Nekem nincs fenn a grafikus felület, mert minek, de helyem sincs rá. Aztán van a sysupgrade parancs, az pedig alapesetben menti a /etc tartalmát, legalább is így emlékszem. Azért nem tudom biztosan, mert a saját konfigjaimat beleteszem az image-be, s így kérdés, az a mentés miatt, vagy az image miatt jó éppen. Különben menti, mert legutóbb változtattam az rc.local-on, s nem változott meg, mert felülcsapta az automatikus mentésével. Mindegy, utána felülírtam, a következő upgrade-nél már azt mentette.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Volt az OpenWrt. Forkolódott, lett a LEDE, meg persze ment tovább az OpenWrt is, de úgy, mint egy sivatag szélén kiszáradt teve. Most, hogy ez a helyzet, s a LEDE-t dinamikusan fejlesztik, békülés van. Lényegében a LEDE megy tovább, kérdés, melyik névvel a kettő közül. Talán a sajátjával, a LEDE névvel.

Kívülről ezt így látom, de van itt a HUP-on a LEDE/OpenWrt project-ben részt vállaló emberke tudtommal, ő tud szerintem hitelesebb infót erről.

Egyébként a routeremen már 4.4.46-os kernel fut, az a legfrissebb longterm. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szivesen irok en nektek executive summaryt... :P

https://lists.openwrt.org/pipermail/openwrt-devel/2016-December/042462…

----
We agreed on giving Imre, Zoltan and Luka commit access to the LEDE
repository so they can migrate changes they care about and which are not
in LEDE, from the OpenWrt repository to the LEDE repository. We also
encouraging everyone who sent a patch, which got merged into OpenWrt and
which is not in LEDE to send it also to LEDE for integration.

----
1. Results from meeting at prpl OpenWrt summit

Agreed upon:

- merging back together
- using OpenWrt as the merged back project name

----

Timeframe:

- target january to merge back together and have time to resolve differences between the teams

Szeretném, ha összefoglalnád saját szavaiddal magyarul, a Google fordító azért még nem tökéletes. Tehát újra együtt? A LEDE az egyesülés után nem folytatja? S OpenWrt név alatt folytatódik? Ugyanakkor a LEDE frissességével?

Mellesleg kinek volt az az őrült ötlete, hogy kiszedje a px5g-polarssl, uhttpd-mod-tls csomagokat a LEDE repókból? Nem baj, ha az image-ekben nincs benne, de legalább a repóban legyen meg. Image-et majd csinálok én magamnak.

Történt ugyanis, hogy nem fér fel a picike routeremre a luci. Kitaláltam, néhány funkcióra csinálok faék egyszerűségű webes felületet awk és ash scriptekkel. Már működött is, mire valamelyik vaddisznó - gondolom, épp az összeolvadás miatt - kiszedte előbb a uhttpd-mod-tls, majd a px5g-polarssl csomagot. Nem volt őszinte a mosolyom, mert ezzel hazavágta a munkámat. Mellesleg hobby volt, nem kell webes felület, teljesen jó az ssh, de akkor is. Kinek árt ez a két csomag, amikor annyi minden van ott még, ami sokaknak nem kell?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A terv a kovetkezo:

- "tovabb dolgozunk a felreertesek es problemak elsimitasan" - ez a marketing
- azokat a commit-okat, amik OpenWrt-ben bentvannak de nincsenek a LEDE-ben, betoljuk a LEDE repoba
- egy adott commitnal a teljes LEDE trunk tree-t visszaemeljuk OpenWrt trunk-ba - ezt fokent azert, mert a split ota valoban tobb fejlesztes kerult a LEDE-be (bar ezek egy resze inkabb atdolgozas, mintsem valodi fejlesztes)
- azt, hogy vegul mergelni fog-e a ket projekt, jo kerdes, de jo esellyel igen, fenntarthatatlan ket kulon projekt ugyanarra a celra

A px5g-s kerdeseidre passz a valasz, mindent nem tudok kovetni en sem a LEDE repoban - nem mi voltunk. :) Bar azt azert zarojelben hozzateszem, hogy - foleg a buildrendszer korul - volt azert par valtoztatas, ami ranezesre csak a "mi" szivatasunkra kerult be.

-w-

hm,
https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd

egy 1043nd v1.X -es szériát (8MB flash / 32MB RAM) frissítettem előbb, 15.X.X WRT-ről LEDE RC-re. LUCI-n keresztül sysupgrade.

Biztos ami biztos előtte toltam egy manual backupot, de gyakorlatilag ~1 perc alatt készen is lett az upgrade + volt net minden féle matatás nélkül.

Ez csak egy gyors visszajelzés. :) (Bár tény, nincs rajta nagyon semmi extra, se ovpn, se semmi egyéb, amit tudnék tesztelni)

ps.: btw egy apró hiba. Ami érdekes.

opkg update és opkg-list-upgradable esetén: 


root@OpenWrt:/tmp/opkg-lists# opkg list-upgradable
luci-lib-ip - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-theme-bootstrap - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-app-firewall - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-proto-ppp - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-mod-admin-full - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-base - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-proto-ipv6 - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-lib-nixio - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1
luci-lib-jsonc - git-17.025.85178-472dc4b-1 - git-17.030.65694-46fd88e-1

opkg upgrade luci-base esetén: 


root@OpenWrt:/tmp/opkg-lists# opkg upgrade luci-base
Upgrading luci-base on root from git-17.025.85178-472dc4b-1 to git-17.030.65694-46fd88e-1...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mips_24kc/luci/luci-base_git-17.030.65694-46fd88e-1_mips_24kc.ipk.
Collected errors:
 * opkg_download: Failed to download http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mips_24kc/luci/luci-base_git-17.030.65694-46fd88e-1_mips_24kc.ipk, wget returned 8.
 * opkg_install_pkg: Failed to download luci-base. Perhaps you need to run 'opkg update'?

Ami azért érdekes, mert a szerveren már a 17.033* git verzió van. Valamiért a Packages fájlban gondolom én, mégis a 17.030-as szerepel.

Érdekes. Na mind1, betudom az RC* résznek :)

UPDATE:

kis kutakodás után igazándiból az a legszebb az egészben, hogy már az opkg update is "kifut" a memóriából és gyakorlatilag nem szedi le a friss Packages* részeket.
Namost, ezt https://forum.lede-project.org/t/17-01-0-rc1-on-wr1043ndv1/1263/3 


sysctl -w vm.min_free_kbytes=0

hirtelen orvosolja ez. Ami viszont érdekes, erre volt bugreport is, elvileg *fixed*ként van jelölve...

https://bugs.lede-project.org/index.php?do=details&task_id=120

Félig meddig "orvosolta" is a min_free_kbytes a gondot. Mivel így az opkg update szépen leszedte a friss Packages listát, be is írta rendesen ahova kell.
Ezek után az opkg upgrade CSOMAG megy is, azoknál a csomagoknál amik pl nem nagyobbak kb. 10kb-nál ..

Pl egy luci-base már nem megy, semmi hibaüzenet, se dmesgbe se sehol. Egyszerűen a kicsomagolásnál meghal az egész. (opkg-TEMP*) alatt ott van az IPK, viszont kicsomagolt verzió már sehol. Csak tekeri tekeri tekeri a routert (eközben megy rendben) és semmi.

Értem én, hogy a 4MB / 32MB-s eszközök "nem annyira támogatottak"... na de basszus egy openwrt 15.0X -el semmi ilyen gondom nem volt ugyan ezzel az eszközzel :/

Értem én, hogy könnyebb panaszkodni, mint megoldani. :)

Csináld a desktop gépeden az image-et akár snapshotból is. A desktop gépen van memória határtalanul, annak a gépnek ez nem feladat. A gond a frissítéssel - ahogy csináltad - az, hogy állandóan hízni fog.

Azért, mert az image egy squashfs, amely erősen tömörített, read only. Efölött van egy overlayfs, amely a változásokat tárolja. Ami frissül, még akkor is az overlayfs-en tárolódik, ha az eredeti file-nál kisebb az új, mert változott. Az idő előrehaladtával egyre több dolog tér el az image-től, így zabálod fel a flash-t a router-edben. Tehát opkg-val ne frissíts, ne telepíts!

Csinálj saját image-et a mindenkori legfrissebb kernellel snapshot-ból - de lehet release-ből vagy RC-ből is akár -, ebbe rakd bele azt, ami kell. Így opkg-val nem kell sem telepíteni, sem frissíteni, mégis a legfrissebb kiadás lesz a router-eden. Az elkészült image-et sysupgrade-del fel tudod tenni a routerre.

Nekem TL-WR841ND v10-esem van, ebben 4 MiB flash, 32 MiB RAM van, amikor kijön új kernel, csinálok egy image-et, aztán feltolom rá.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

btw, nem panaszkodni akartam, csak leírtam a tapasztalataimat ^^

De az azért mégse legyen már egy megoldás, hogy saját image-et gyártok, mert van egy bug a LEDE* féle opkg (vagy mittudomén melyik részben) csomagban.
Mert akkor ennyi erővel bármire gyárthatnék saját image-et. És ha LEDE projekt sikerre akarja vinni, akkor bizony nem arra kellene hogy építsen, hogy majd mindenki
buildel magának saját image-et :) Ez csak egy saját vélemény, de szerintem megállja a helyét.

openwrt-vel nem volt ilyen problémám. Csak erre akartam rámutatni.
Természetesen volt bugreport lede* fele. Nem csak tőlem szerintem, mástól is. Maguk is elismerték, hogy igen az opkg* részben vannak ilyen bugok.

Szóval, nem panaszkodás volt, csak egyszerűen leírtam én mit tapasztaltam :)

ps.: ettől függetlenül teszi a dolgát a szerkezet is meg a LEDE is.

Ebben az valóban bug, hogy csinálja a frissítést, amíg tudja, s ha éppen csomag közben fogy el a hely, akkor ott száll ki belőle, ami kínos, mert lesz egy félig új, félig régi csomagod. Kevésbé kínos viszont azért, mert a változások az overlayfs-en vannak, így takarítással elvileg helyre tudod rázni a korábbi állapotot, de ez munkás. Jó volna, ha az opkg előbb ellenőrizné a méretet.

Ugyanakkor, ha ellenőrzi a méretet, akkor sem fog felférni az újabb csomag a flash-re, pusztán annyival lesz jobb a helyzet, hogy nem egy félbehagyott, inkonzisztens állapotot hagy maga után. Mondjuk ez nem elhanyagolható előny valóban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Alucard | 2017. 02. 05., v – 06:00 )

Gond nélkül frissítettem OpenWrt-re:

Model: TP-Link TL-WR1043N/ND v2
Firmware Version: LEDE Reboot 17.01.0-rc1 r3042-ec095b5 r0+3043-68a04db / LuCI 472dc4b9e2ca71c114f5da70cb612c1089b8daa7 branch (git-17.025.85178-472dc4b)
Kernel Version: 4.4.42

--
Debian GNU/Linux