Inlägg

pga nyligen uppkomna strulen med c2xxx korten på marknaden, så tänkte jag nog fundera på vad jag köper om mitt c2550d4i dör..

tanken just nu pekar mot ett Asus P10S-I (då jag har krav på mITX formfaktor då jag i nuläget inte vill byta ut chassie etc.)
processor blir troligen en E3-1230v5 och det blir ecc ram pga zfs.

någon som provat Asus P10S-I? hittar typ inte en enda seriös review på nätet av kortet?

Har pratat med dom, och det verkar vara så att om det inte är trasig nu, så gäller det bara fram till 3år från inköpsdagen (dvs lev av kort #1).

om asrock senare tar på sig en rma på goodwill eller liknande, det får man se om det går sönder efter 3års gränsen..
verkade inte på dustin som dom hade någon direkt info kring detta ännu, jag visste mer än supporten..

nåja enda vettiga med detta är att man kan förbereda en plan b om skiten rasar, men skulle jag kunna klämma 2-3år till ur moderkortet blir jag ju glad, inte riktigt vad jag vill lägga pengar på nu..

lät ju mindre bra..
om man utgår ifrån beställningsdatum för kort #1 (åkte tillbaka på rma pga doa om ja minns rätt) så borde mina 3år gå ut någonstans runt 28/3-10/4 beroende på om man räknar dagen jag hämtade kortet på posten eller beställningsdagen..
kort #2 åkte på rma 10/5 då det var instabilt...
kort #3 dog någonstans under hösten, och fick det sista kortet #3 i typ oktober. det börjar närma sig 2½år nu det sista kortet...

nåja ska ringa och kolla med levrantören imorron. får vi se om det blir ett kort #4 eller om det får leva tills det dör, isf blir det inte ett till asrock kort iaf efteråt..

hur går förlängd rma till?

tar man kontakt direkt med Asrock eller med företaget man köpte kortet via?

anledningen till frågan är att jag tror det börjar bli akut för att hinna med inom 3års gränsen för mitt asrock c2550d4i...

liten update..

sen jag köpte nya sata kablarna har jag inte haft ett enda read error... och det är ett rätt bra tag sen..

nu är det dags igen för lite omskiftningar på servern, blir att byta från arch linux (lts kernel) till nya freenas 10(-rc1 just nu)

anledningen till att jag hamnade hos freenas den här gången är mest för att se om freenas lyckas hålla nere cpu loaden vid lite hårdare tag vad det gäller skrivningar till poolen. hittills funkar det bra.

sen såg jag precis att asrock släppt bmc 0.30.00... så det blir väl en bmc updatering också..

nån som provat bmc 0.30? släpptes 2/15/2017

har lyckats bricka en brix (två snabba strömavbrott när den direkt autobootar om sig efter strömavbrott),
visade sig vara on/off knappen på grenuttaget som glappade.

efter detta låser den sig på gigabyte postscreenen, så misstänker att det som behövs är att flasha om uefi firmwaren.

någon som vet om det går att göra på brix direkt vid bootup eller om det är mer jobb än så att flasha om en brickad brix...
enda jag hittar på deras sida måste man komma förbi posten...

garantin har gått ut sedan länge, så från gigabyte lär ingen hjälp komma, som inte är billigare att köpa en ny..

okej udda grej..

har ett admin konto detta har massa mappar och filer som till storlek är små största filerna är väl 25mb..

denna är utdelad till massor av konton, då det med tiden kommer bytas ut folk åt höger och vänster, men filerna måste vara accessbara för dom nya.

att synca från oc till client OK.
att från klienten lägga till en fil, så den ska läggas till i den delade mappstrukturen. Fail..

 2016-09-13 13:34:37,xxxxxx Dokument/xxxxxxx/xxxx xxxx.pdf,           xxxx.xxxx.se,Objektet kunde inte synkas på grund av tidigare fel: Error transferring https://xxxx.xxxx.se/remote.php/webdav/xxxxxx Dokument/xxxxxxx/xxxx xxxx.pdf - server replied: Insufficient Storage (Sabre\DAV\Exception\InsufficientStorage)

har lagt en 1Gb quota på delade kontot, samt 512mb på dom andra, mest för att ingen ska råka fylla hela servern...

oc clienten visar korrekt datamängd på ca 400mb, således borde inte ett pdf dokument på ca 2mb bryta några quotas.. varken för användaren eller admin kontot..

för visst ska alla kunna ladda upp filer i en delad mapp?

edit: fixade det genom att ta bort Quotan på admin kontot, så går det att synca nya filer, men dom som redan fastnat i InsufficentStorage träsket får man manuellt ladda upp i webinterfacet... så försvinner dom från listan..

var tydligen någon gammal surdeg som hängt med ett tag i buglistan..

mmm... dom som ger en flest grå hår per timma felsökning...

okej lika bra och delge hur jävla korkat det här var då...

körde en yum update som uppdaterade php tidigare idag...
gissa vad som händer på Centos 7..
jo den återställer ägaren till session.save_path i php-fpm.d/www.conf...

/var/lib/php/session fick ägaren root:apache isf root:nginx som jag hade ändrat tidigare..

när jag väl hittade att att owncloud hade en egen logfil som loggade dom bitarna i data mappen, så var det lätt återgärdat..
för errorloggen i nginx blev man ju inte klokare av...

alltid kul med simpla fel som man tror är något helt annat..

hmm någon som har koll på varför man skulle få csrf errors vid login?

visade sig att clamav inte ville lira som det skulle, fixade det, tror det var allt jag pillade i, sedan slutade login funka och ger csrf errors, jag hittade att i 9.1 så finns de en bug som har med files_sharing appen, men disablar jag den så fortsätter den att ge samma error...

verkar ha något med att den tror att det är något exploit försök som jag förstått vad csrf var för något..

ok bra att documents appen funkar i NC(9).

det finns ju libreoffice-online men den är inte stable ännu...

när den blir stable, så ska jag prova libreoffice-online, men det känns som det är en bit kvar där också..

men dom baserade 1.6.0 på CODE, vilket är utvecklingsversion..
sista releasen jag såg var 1.7.2, och det kommer ju releases nästan dagligen..

jag tror faktiskt jag får vara feg och hoppas att NC10 kommer och att det går att migrera från oc9.x utan större bekymmer. i värsta fall går det väl att sätta upp fedrated sharing och köra båda side by side under en mig. period tills allt funkar som det ska i NC..

problemet som jag ser är att det är att en del av användarna som ska använda installationen inte är så hajj på nya saker, så jag vet att först kommer jag behöva lära dom använda OC, sedan den dagen det är dags att byta till NC så lär jag få börja om från ruta ett..

Documents appen ser jag iofs som en dealbreaker...
det är ju en av dom viktigaste apparna som måste funka..

den har jag dock en kanske udda fråga om? går det att spara nya dokument som doc eller docx i documents? eller måste man spara odt, sen via libreoffice på clienten konvertera till docx?

det är några som hellre använder ms office än libreoffice...

har libreoffice-{headless,writer,calc,impress} installerade på servern, men nya dokument blir oavsätt hur jag gör odt, men den kan öppna doc och docx...
(skulle vara trevligt om xlsx och pptx funkade också, men det är inga direkta dealbreakers, eftersom documents bara supportar writer..)

har centos 7 plus som os..

hur länge bör man vänta med att switcha owncloud till nextcloud för prod saker som man inte vill ha massa strul med?

det är ju ownclouds kodbas, men dom lär ju gjort ganska stora modifieringar..?

så man vill nog att folk ska hinna testa ut det ordentligt innan...

enligt nån sida jag hittade skulle det gå att migrera vid 9.1 -> NC10 när det väl dyker upp.. men det betyder att jag inte bör uppdatera vidare på oc9.x serien från 9.1 när dom uppdateringarna kommer då?

# Handles letsencrypt validation challenge and redirects to https from http
server {
        listen 80;
        server_name my_domain.com subdomain.my_domain.com;
        location /.well-known/acme-challenge {
                default_type "text/plain";
                root /usr/local/www/; 
        }
        # Redirect to https
        location / {
                return 301 https://$server_name$request_uri;
        }
}

grymt! funkar fina fisken... både ssl redirecten och letsencrypt på port 80 som är rekomenderat...

tackar

server {
# The IP that you forwarded in your router (nginx proxy)
  listen 192.168.1.112:80; # this is not the default_server

# Make site accessible from http://localhost/
 server_name xxx.se;
 server_name www.xxx.se;

 return 301 https://xxx.se$request_uri;


}

server {
# The IP that you forwarded in your router (nginx proxy)
# this is not the default_server
  listen 192.168.1.112:443 ssl;

# Make site accessible from https://localhost/
 server_name xxx.se;
 server_name www.xxx.se;

location ~ /.well-known {
                allow all;
        }

 ssl on;
 ssl_certificate /etc/letsencrypt/live/www.xxx.se/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/www.xxx.se/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;

 # intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES12$
    ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;


# The internal IP of the VM that host you Apache config
 set $upstream 192.168.1.115;

 location / {

 proxy_pass_header Authorization;
 proxy_pass https://$upstream;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 proxy_buffering off;
 client_max_body_size 0;
 proxy_read_timeout 36000s;
 proxy_redirect off;

 }

}

ja den såg definitivt annorlunda ut än standard varianten...

saknas alla nginx varianter av htaccess blockeringar (det som troligen genererar min 404..)

ska kolla igenom länkarna lite senare, det konstiga är just att letsencrypt och nginx inte är problemet.. det är just en av nginx vhost filerna som strular, jag har nämligen 3st subdomäner, varav endast cloud (som har ownclouds nginx config fil) strular..

misstänker att det är någon av alla direktiv som ska funka som en htaccess och generera 404 som kickar in..

enda skillnaden jag har är att jag inte har en tom acme-challenge, utan pekar till en annan rootdir samt allow all...

men endå verkar den sparka bakut.. fick det att lira en gång.. men det var innan jag flyttade webrooten (i acme-challenge) för cloud subdomänen..

så har väl 90 dar på mig att få skiten o funka innan certet blir obrukbart..

i värsta fall får jag när jag kör cert uppdateringar sänka nginx och dra upp certbot standalone mode på port 80.. då vet jag att det funkar, men vill helst slippa ta ner sidan då ifall något crashar så blir det massa downtime.. bättre om nginx kan rulla som vanligt..

du får gärna posta det som har med owncloud att göra, misstänker att det har med regex uttrycken att göra som pekar till en 404... frågan är bara vilken...

någon som bråkat med letsencrypt och nginx (1.6.3) tillsammans med owncloud?

av någon skum anledning köper den inte acme-challenge mappen i configfilen...

    location /.well-known/acme-challenge {
        root /var/www/letsencrypt;
        allow all;
    }

direkt efter dom andra två .well-known direktiven som finns i standard templatet för owncloud 9:

    location = /.well-known/carddav {
        return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
        return 301 $scheme://$host/remote.php/dav;
    }

försöker jag nå en fil (lagt en temp fil bara för att ha en fil att hämta ur den dirren utan att köra certbot hela tiden...

iaf i nginx accessloggen får jag en 404 och sedan en redirect till ownclouds 404 sida.. dvs samma sak som händer i browsern...

måste ju vara att den matchar det till en av alla locations som linkar direkt till 404 errors?

för dom andra vhost'sen funkar samma acme-challenge fint på, bara owncloud som skickar den vidare till 404...

så fick jag arslet ur vagnen och faktiskt köpte lite sladd..

blev startech lsatarnd12 kablar, efter lite mätande ansåg jag att 30cm kabel längd borde bli ganska perfekt i ett ds380 chassie med asrock kortet..

och nu är det monterat och klart, och det blev tight och fint, och va mycket mindre plats det tar än 10st vanliga sata kablar, dom gamla var dock ca 45cm långa.

klart nöjd hittils.. mjuka och fina kablar och priset gick inte att klaga på... typ 55:- styck..

tråkigt med trasiga kort, men att dom tog in kortet på rma efter garantin gått ut är ändå en positiv sak..

root@www:/usr/ports/devel/pecl-APCu # make install
===>  pecl-APCu-4.0.10 cannot be installed: doesn't work with lang/php70 port
(doesn't support PHP 70).
*** Error code 1

Stop.
make: stopped in /basejail/usr/ports/devel/pecl-APCu

på arch linux wiki var förut redis det som rekomenderades, numera står det inte ett ord om redis utan apcu, måste vara arch linux specifikt, då det är i deras wiki jag hittade det.. arch wiki oc

en sak jag kom att tänka på, du hade problem med vit sida va? har du kollat igenom alla loggar till webserver, php och owncloud?
kört en phpinfo(); via nginx? vill minnas att med någon version av php5 på freebsd 10.2 så hade jag en bug med php-fpm som gjorde att den inte laddade extentions som den skulle i php-fpm, medans vanliga php samt php-cli funkade som det skulle..
då fick jag bara vit sida utan några felmeddelanden någonstans vad jag kan minnas.. pga att det var någon extention som owncloud behövde..

men det är säkert ett halvår eller mer sedan.. så det kan vara fixat nu, men sedan dykt upp något liknande i nya php7..

på arch linux wikin (se quote ovan) var rekomendationen APCu, förut var det redis, säkert jag som rörde till det..

Available commands:
  check                               check dependencies of the server environment

uppdaterade precis till php7 och OC9.0.0...

i php7 verkar redis.so (iaf på arch linux) ha någon symbol missmatch mot php7 efter uppdateringen..

[stingray@Thor owncloud]$ sudo ./occ-with-cli-env check
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/openssl.so' - /usr/lib/php/modules/openssl.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/posix.so' - /usr/lib/php/modules/posix.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/redis.so' - /usr/lib/php/modules/redis.so: undefined symbol: zval_used_for_init in Unknown on line 0
ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade

openssl.so, posix.so är inbyggda så dom ska bort ur php.ini filen..

från archlinux php7 nyhet..

openssl, phar and posix extensions are now built in

genom att fimpa dom inbyggda extensions samt redis mot apcu (behövs php-apcu-bc på archlinux för bakåt kompatabilitet med apc osäker hur freebsd har lagt upp dom grejerna) så hoppade owncloud snällt igång igen.. sen får man fixa till owncloud configen för att använda apcu isf redis..

min första tanke är vad mycket snabbare owncloud blev med php7 (+ apcu) än php56 + redis

funkar redis + php7 för dig på ubuntu? funkade iaf inte för mig på arch linux..