Den frie kafeen

[stigfjel]

Ubuntu blir værende på laptopen. Bruker Unity og har ikke tenkt meg noe sted med mindre det har skjedd noe alvorlig galt mellom 12.04 og kommende 14.04, noe det såvidt jeg har skjønt ikke har.

 

Til serveren tenker jeg kanskje å være så modig at jeg beveger meg over på 14.04 før den er helt ferdig for å få litt ferskt btrfs-stæsj^^ Hvis en eller annen fornuftig form for Debian kan gjøre det og være greit stabil i samme slengen så er jo det veldig aktuelt.

Du har jo zfsonlinux. Fungerer ganske bra på CentOS, i hvert fall.

[hernil]

Har kikket litt på det tidligere også, men er noen ulemper for min bruk.

- Vanskelig å utvidde raid senere

- En ekstra ting å tenke på ved oppdateringer/oppgraderinger som kan gå meget galt. Filsystem er egentlig ikke noe jeg vil bruke tid på hverdagen når ting først er sattt opp.

 

Btrfs er nok litt umodent, men til min bruk som hjemmeserver med relativt beskjeden last så tror jeg det skal gå helt fint. Det skjer stadig arbeid på det og jeg får det nyeste ved å oppdatere kjernen.

[Lycantrophe]

stigfjel: tror ikke vi har vært inne på det før, men uansett. For hjemmeserveren ser jeg få problemer med Debian. Stable er gjerne stable et par år, og oldstable lever enda et år. Hjemme er ikke det noe problem synes jeg - jeg trenger ikke 10 år support der. Spesielt ikke om jeg skal tukle med ting som btrfs.

 

Når det er snakk om jobb eller viktigere tjenester hadde jeg tatt CentOS/RHEL uten å blunke.

 

edit: kan forøvrig nevne at jeg kjører Debian på alt. Jeg har egentlig ingen argumenter for å skyte inn CentOS i nettverket mitt.

Endret 9. februar 2014 av Lycantrophe

[stigfjel]

De siste årene (helt siden 2007 med Debian 4.0 "Etch") har det gått ca 2 år mellom hver release av Debian Stable. Det gir en levetid på 3 år for en release. Etter de 3 årene blir ikke releasen vedlikeholdt. Men det er situasjoner hvor Debian er hensiktsmessig. Ett eksempel er hvis jeg skal sette opp en IMAP mailserver basert på Courier. Debian har de pakkene som trengs, i CentOS må noen pakker kompileres, og man må bruke repoer som egentlig ikke passer til CentOS (f.eks. rpmforge istedenfor EPEL).

 

Hjemme bruker jeg også Debian, men da til multimediamaskin. Fungerer alldeles utmerket. Så jeg er ingen Debian-motstander, men Debian passer ikke til alt. Hva angår kickstart-installasjoner, så fungerer det helt utmerket på RHEL/CentOS.

[Lycantrophe]

Jeg har ingen problemer med det til hjemmeserveren heller. Men det er noe begrenset hva jeg kjører der, og tre år er plenty.

 

That being said var det ikke skrekkelig mange pakkene jeg brukte som fikk særlig forandring fra Squeeze til Wheezy.

[JonJ]

 

Det var tydeligvis bare dårlig kommunikasjon.

 

http://lizards.opensuse.org/2014/02/03/trying-to-add-some-light/

 

Sitat fra siden: "SUSE is NOT decreasing manpower put into openSUSE"

Det er jo bra for SUSE. Men det bidrar jo til å skape usikkerhet rundt SUSE som alternativ for enterprise Linux.

 

På hvilken måte da?

[stigfjel]

På hvilken måte da?

Enterprise-segmentet er opptatt av at det produktet man benytter har stabile fremtidsutsikter. Slike utspill som at SUSE kutter ut betalte ansatte for å jobbe med OpenSUSE bidrar til å skape usikkerhet og forvirring. Det sier de jo selv:

 

Lately there was some confusion regarding our communication. We, at the openSUSE Team@SUSE are deeply aware that our communication needs to be improved. So in the hope to make everything clear again, here is the summary to clear up what is really going on and what was not happening.

 

For et enterprise-OS er det ganske viktig at det er stabile forhold i prosjektet. Skrekkeksempelet er CentOS, som mer enn en gang har vært nær ved å gå under. Først i 2008 da lederen dro på ferie, hvor han tok med seg alle passord og prokurarettigheter, resten var låst ute og kunne ikke gjøre noe. I 2010/2011 var det interne stridigheter i CentOS, en core-utvikler sluttet, hvilket medførte at CentOS 6 ble flere mnd forsinket. Red Hat rakk å slippe RHEL 6.1 før CentOS 6.0 kom ut. Og det kom ikke en eneste sikkerhetsoppdatering til CentOS på nesten et halvt år. I enterprise-sammenheng er det en skandale, og grunn nok til ikke å velge det produktet. Jeg har selv advart mot CentOS i kjølvannet av den saken. Nå er derimot saken en helt annen: Red Hat har nå begynt å betale lønn til personer for å jobbe med CentOS, noe som gjør CentOS til et langt bedre valg i dag, altså det motsatte av det SUSE så ut til å gjøre, men som de nå har dementert. Men nå vil jeg uansett ikke bruke SUSE i enterprise-sammenheng, de bumper visst versjonsnr av forskjellige pakker innenfor en release. Red Hat på sin side holder seg til backporting, noe som er et sikrere alternativ mtp. kompatibilitet med annen programvare.

[Del]

Debian på hjemmeserver er finfint. Btrfs fortjener også frisk melding nå. Ville riktignok godt over til Debian testing for å få grub 2.0, har hatt ymse erfaringer med eldre grub og btrfs som rotfilsystem. Til gjengjeld vil dagens testing holde omlag fem år.

[Simen1]

TU.no har en ny liste over bidragsytere til Linux-kjernen. Kilden er Linux Foundation.

[stigfjel]

TU.no har en ny liste over bidragsytere til Linux-kjernen. Kilden er Linux Foundation.

Vi ser at det er Red Hat som er den største kommersielle bidragsyteren. I tillegg driver de en rekke open-source prosjekter som er mer eller mindre nyttige, og nå sist er de blitt en solid bidragsyter til CentOS, hvor de nå betaler folk for å jobbe med nettopp CentOS. Det i seg selv er et veldig godt argument for at man bør velge RHEL i kommersiell sammenheng, en god del av de pengene man betaler for Red Hats support flyter tilbake til videreutvikling av open-source produkter. I tillegg er jo RHEL et fjellstøtt operativsystem, meget godt egnet for stabil serverdrift.

[olear]

Bare ikke installer den på desktop (GNOME/KDE som følger med har så mange bugs at det er vankelig å bruke distroen i en dag uten at noe krasjer eller endrer seg).

 

Bruker selv CentOS på en del servere, fungerer fint (etter mye modding). Eneste problemet med CentOS er at de ikke følger Major.Minor, har du release 6, har du 6.5 uten valg, kommer 6.6, da må du oppdatere til den, eller aldri oppdatere igjen. Dette er ikke alltids så gunstig da RHEL nesten alltids breaker noe ved ny minor. Å oppdatere kernel er vanligvis et sjangsespill, spesielt på desktop.

[stigfjel]

Å oppdatere kernel er vanligvis et sjangsespill, spesielt på desktop.

Derfor man har test/stage servere. Klart, ikke alltid det lar seg gjøre rent praktisk.

 

Jeg kom borti en interessant ting engang. Skulle patche en RHEL-server (brannmur) med et komplisert nettverksoppsett (bonding med VLAN-tagging). Og det var en minor-release som skulle inn. Det gikk ikke så bra. Viste seg å være en bug i den kernel-releasen, måtte vente til det kom en kernel-patch. Imens kjørte jeg på gammel kernel.

[olear]

Klart man tester først, problemet er bare at det kan ta en stund før en ny kernel (med evt. fix) dukker opp, så man må sitte på en gammel kernel på ubestemt tid (så lenge det ikke går utover sikkerhet går det jo greit), finnes mange kernelbugs som ble introdusert i 6.1, og har aldri blitt fikset (de vet om det). Kjipt å måtte sitte på en kernel fra 6.0 når man kjører 6.5, før eller senere vil det gå galt (6.7 introduserer noe nytt og dumt, krever kernel 2.6.32-hundreogti).

 

Uansett, RHEL/CentOS på server fungerer veldig bra, enkelt vedlikehold og i utgangspunktet stabilt.

 

Vanligvis bruker jeg custom repo, slik at jeg har total kontroll over oppdateringene.

 

EDIT: 6.5 brøyt med wireless apien, og jeg måtte fikse flere trådløsdrivere slik at de kompilerte igjen, da hadde RHEL fjernet den gamle API. Skummelt på "the" LTS-distro.

Endret 11. februar 2014 av olear

[kpolberg]

Er vel stort sett bare en ting som irriterer meg med RHEL/CentOS for tiden, og det er det der forferdelige NetworkManager styret. Forsåvidt greit på en laptop, men på en server...

[endrebjo]

Jeg prøver å få inn Multicast IPTV (Uninett) på en CentOS 6.5 desktop-maskin, men det virker som om OS blokkerer multicast. Etter å ha fiklet en del prøvde jeg som en siste løsning å deaktivere brannmuren vha.

service iptables save
service iptables stop

Men heller ikke det ga resultater.

Kan det være noe annet enn brannmuren som blokkerer? Og hvordan henger iptables og system-config-firewall sammen egentlig?

[AM2petterk]

Jeg prøver å få inn Multicast IPTV (Uninett) på en CentOS 6.5 desktop-maskin, men det virker som om OS blokkerer multicast. Etter å ha fiklet en del prøvde jeg som en siste løsning å deaktivere brannmuren vha.

service iptables save
service iptables stop

Men heller ikke det ga resultater.

Kan det være noe annet enn brannmuren som blokkerer? Og hvordan henger iptables og system-config-firewall sammen egentlig?

Sjekk at om du har følgende i /etc/sysctl.conf:

 

 

net.ipv4.icmp_echo_ignore_broadcasts = 1

Hvis du har det, sett den til 0 istedet.

 

Usikker på om det er problemet ditt i dette tilfellet, men det er noe av det letteste å sjekke iallefall.

[stigfjel]

Er vel stort sett bare en ting som irriterer meg med RHEL/CentOS for tiden, og det er det der forferdelige NetworkManager styret. Forsåvidt greit på en laptop, men på en server...

I /etc/sysconfig/network-scripts/ifcfg-ethX:

 

NM_CONTROLLED=no

[kpolberg]

hehe, er fullt klar over at det går an å deaktivere, og vanligvis tar jeg en chkconfig NetworkManager off i tillegg. Måtte bare nevne hvor irriterende jeg synes NetworkManager er

[dabear]

Noen som har erfaringer med bruk av http://en.wikipedia.org/wiki/Glusterfs ? Spesifikt mellom to siter. Noe man bør ta høyde for? Noen drawbacks?

[kpolberg]

Forsøkte engang med glusterfs replicated volum på en mailserver over WAN(Lyse 25mbit linje i begge ender), det fungerte dårlig... Kan være det hadde fungert med geo-replication, men da hadde jeg egentlig ikke oppnådd det jeg ønsket.

 

http://gluster.org/community/documentation/index.php/Gluster_3.2:_Replicated_Volumes_vs_Geo-replication