Linux-skills till Seagate NAS

[Mikael_L]

Sådär. Nu kommer du någonstans. Det här är alltså definitionerna av dina shares. Vad var det du ville göra nu igen?
Om du ska ha en share som är läsbar för alla men skrivbar endast för dig borde det räcka med att lägga till alla användare i valid users, like so; valid users = "admin, testuser, nobody"

Ohhh, äntligen lite success ...

Med
valid users = "admin", "testuser"
(inte valid users = "admin, testuser" )

Så kom jag äntligen in i testuser's mapp inloggad som admin.

Nu känns det som att jag är på gång.

(Det ska sen bli spännande och se vad denna "NAS" tar sig till vid omstart, om allt skrivs över med något slags defaultdata ... :|)


Jag måste gå och knyta mig nu för kvällen, blev för toksent igår, måste vara piggare imorgon.

Men imorgonkväll ska jag fortsätta utforska denna lilla Linux-dator.

 

[tommib]

Ah... nu inser jag att du frågade efter hur man "startar om" samba, inte hur man "startar" om samba
Men kul att det går framåt. Kolla om du kan skapa filer med den ena användaren och radera med den andra, mm....

Sömn är för mesar! Lycka till!

 

[Mikael_L]

Ja det googlade jag nog fram.
Skriver detta (precis varsomhelst i katalogstrukturen)
/etc/init.d/samba force-restart

(Men konstigt nog kan jag inte stå i katalogen /etc/init.d/ och skriva samba force-restart
Tycker jag intuitivt borde vara samma sak ... :|

 

[tommib]

Nope, Linux fungerar inte så. Om du däremot skriver ./samba force-restart när du står i /etc/init.d så funkar det. Punkt (.) är referens till aktuell katalog och dubbelpunkt (..) är katalogen ovanför. Aktuell katalog är av säkerhetsskäl aldrig med i PATH som är miljövariabeln där ditt skal letar efter ett program med namnet du har skrivit in. När du skriver på första sättet ger du hela sökvägen, således hittar skalet programmet du försöker köra.

Observera att det inte går att skriva cd.. som man gjorde i dos för hundra år sedan utan man måste skriva cd .. (alltså med ett mellanslag). Det är för att Linux måste skilja på kommandot (cd, change directory) från mappen du vill till (.., dvs mappen ovanför aktuell). Bara en liten lustig skillnad som egentligen är helt logisk, det är Windows som obfuskerade en komplexitet (i deras ögon).

 

[123abc]

Ja det googlade jag nog fram.
Skriver detta (precis varsomhelst i katalogstrukturen)
/etc/init.d/samba force-restart

(Men konstigt nog kan jag inte stå i katalogen /etc/init.d/ och skriva samba force-restart
Tycker jag intuitivt borde vara samma sak ... :|

Om du står i katalogen och vill köra ett skript i samma katalog ./ före alltså ./samba force-restart så den förstår att den ska köra ett skript i från den katalogen du befinner dig i istället för att leta efter skriptet i path.
Om du testar "echo $PATH" så ser du vilket path skalet använder med aktuell användare.
Punkten "." (dot operator) är något som används i olika skal t.ex bash i linux och där punkten tolkas som kommandot source men även current directory med ./ (jag tänker inte förklara subshell mm då det blir för mycket OT).

 

[tommib]

Om du står i katalogen och vill köra ett skript i samma katalog ./ före alltså ./samba force-restart så den förstår att den ska köra ett skript i från den katalogen du befinner dig i istället för att leta efter skriptet i path.
Om du testar "echo $PATH" så ser du vilket path skalet använder med aktuell användare.
Punkten "." (dot operator) är något som används i olika skal t.ex bash i linux och där punkten tolkas som kommandot source men även current directory med ./ (jag tänker inte förklara subshell mm då det blir för mycket OT).

Du läste inte ovanför eller

 

[123abc]

Du läste inte ovanför eller

Jo det gjorde jag men jag vidareutvecklade lite till, men jag läser dåligt och kanske filtrerade bort lite ur ditt inlägg när jag läste
Nu är punkten mer magisk än så framförallt som först i filnamn för dolda filer men jag väljer att inte utveckla för mycket.
Det är även skillnad på var punkten används i kommandot före är det source men efter är det aktuell katalog.
Precis som "cd" även kan utvecklas betydligt mer men det finner jag totalt utanför ämnet.

 

[A-Man_08]

Produkten låter rätt krånglig och omständig.

 

[tommib]

Jo det gjorde jag men jag vidareutvecklade lite till, men jag läser dåligt och kanske filtrerade bort lite ur ditt inlägg när jag läste
Nu är punkten mer magisk än så framförallt som först i filnamn för dolda filer men jag väljer att inte utveckla för mycket.
Det är även skillnad på var punkten används i kommandot före är det source men efter är det aktuell katalog.
Precis som "cd" även kan utvecklas betydligt mer men det finner jag totalt utanför ämnet.

Nja. Punkten är aktuell katalog och expanderas så. Om det används innan kommandot expanderar den till aktuellt katalognamn och ger en fullständig sökväg. Om den används efter sker samma sak. Så ingen skillnad.
Men ja, som första tecken i filnamn gör den filen dold, det är riktigt. Kontexten är dock annorlunda där.

 

[123abc]

Nja. Punkten är aktuell katalog och expanderas så. Om det används innan kommandot expanderar den till aktuellt katalognamn och ger en fullständig sökväg. Om den används efter sker samma sak. Så ingen skillnad.
Men ja, som första tecken i filnamn gör den filen dold, det är riktigt. Kontexten är dock annorlunda där.

Nej där håller jag inte alls med ". test" är samma som "source test" medan i kommandot "cp /tmp/test ." så betyder punkten aktuell katalog.
./ är en relative path som pekar mot aktuell katalog.
Punkten "." är typisk för utanför path variabeln.

 

[Oldfart]

Att . tolkas som aktuell katalog och .. som ovanstående katalog i en sökväg slogs fast i 1003.1-1988 som en del i specifikationen av unix. Därmed är det implementerat i det grundläggande systembibliotek som ligger direkt ovanpå operativsystemets systemanrop. Sett från operativsystemets perspektiv finns det inga dolda filer. Punkt har ingen särskild betydelse över huvudet taget i filnamn.

Att . i början av en rad tolkas som source-kommandot är däremot något helt annat. Det är en funktion i kommandotolken Bourne Shell och dess efterföljare. Precis samma sak med att filer som börjar men en punkt inte visas av ls-kommandot eller matchas av wildcards i en del lägen.

 

[Oldfart]

Kan även vara värt att veta att . och .. ofta lagras på disk, och därmed är en del av filsystemets struktur. Någon skrev tidigare att de "expanderas" till rätt värde, vilket alltså är helt fel. De dolda filerna dök dessutom upp oavsiktligt som en bugg när en av unix skapare var lat och skrev kod som enbart tittade på första bokstaven för att sortera bort de filnamnet istället för att explicit jämföra hela namnet mot "." respektive "..".

Så här beskrev Rob Pike det i en post för några år sen:

A lesson in shortcuts.

Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:
if (name[0] == '.') continue;
This statement was a little shorter than what it should have been, which is
if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;
but hey, it was easy.

Two things resulted.

First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.

Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.

I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago?

Keep that in mind next time you want to cut a corner in your code.

(For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.)

 

[123abc]

Att . tolkas som aktuell katalog och .. som ovanstående katalog i en sökväg slogs fast i 1003.1-1988 som en del i specifikationen av unix. Därmed är det implementerat i det grundläggande systembibliotek som ligger direkt ovanpå operativsystemets systemanrop. Sett från operativsystemets perspektiv finns det inga dolda filer. Punkt har ingen särskild betydelse över huvudet taget i filnamn.

Att . i början av en rad tolkas som source-kommandot är däremot något helt annat. Det är en funktion i kommandotolken Bourne Shell och dess efterföljare. Precis samma sak med att filer som börjar men en punkt inte visas av ls-kommandot eller matchas av wildcards i en del lägen.

Att . och .. beskrivs i posix.1 standarden 1003.1-1988 ifrågasätter jag inte men det är inget som är unikt för unix när det gäller sökvägar (path).
Även i dos och windows cmd.exe används .. för upp ett steg i sökvägen och . för aktuell katalog vilket det gör i posix kompatibla operativsystem.
Ni som använt windows powershell känner även igen att "." används som source där med, jag vill minnas att microsoft kallar det dot sourcing operator. https://technet.microsoft.com/en-us/library/hh847732.aspx
Detta är alltså inget som är unikt för ett bash skal i linux utan en del av posix standarden. (jag länkar till aktuellt stycke för att diskussionen inte ska dra iväg)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot

 

[Mikael_L]

Produkten låter rätt krånglig och omständig.

Menar du seagate central?

Då skulle jag vilja säga nej.
Men däremot har den antingen begränsad grund-funktionalitet alternativt verkar man kunna göra väldigt mycket den om man är beredd på att krångla och vara omständlig.

I grunden är den väldigt enkel att sätta igång. Slå igång - välj ett username och password för den första sharen som dessutom får administratörsrättigheter.
Lägg sen in ev andra som ska nyttja disken, allt via webgränssnitt.

Nu är det igång, men med så enkelt funktionalitet att jag tycker inte att enheten ska kallas NAS. Och det tycker nog seagate också, då den ej får samsas med deras riktiga NAS i produktträdet.

Denna produkt är, i sitt grundutförande, mest att se som en extern HD, nätverksansluten isf USB-ansluten.
Dessutom kan den agera extern HD åt flera användare samtidigt.

Den är däremot en usel hjälp för att dela filer mellan flera användare på ett kontrollerat sätt.

 

[tommib]

Ok, jag hade fel
Men då har jag lärt mig något nytt nu också