За маунтването има значение owner-а и групата на устройството. След като се маунтне вече има права който са на маунт поинта, има и права вътре във самата маунтната система. Въобще руута на маунтатата система може ли да си има собствени права? И ако да - как се променят те?
Питам, защото имам няколко диска в нас, на които стоят музики, филми и подобни простотии, които по принцип е хубаво да са общодостъпни, но понеже само аз си ползвам щайгата в момента е просто някак закърпено, а искам да го направя като хората.

пробвай с

Код

GeSHi (Bash):
route add default gw адрес

като на мястото на адрес сложиш gateway-a който искаш да ползваш (предварително влез като руут : sudo su -)

Да, прав си за umask-а, само че един приятел админ ми каза, че новата философия на всички дистрибуции е umask=0022 (объркал съм го в предишния пост) - т.е това дето преебава философията за директория със set gid. Има ли някакъв начин да се force-не umask=0002 в дадена директория, за да не може някой 'заспал' user да създаде нещо, нечетимо/неписуемо за останалите? А по въпроса с mount-ването на разни дялове ако може да дадеш някой по-пространствено четиво ... 

Имам едно (две) въпросче по темата:

Има ли някъде подробно обяснение с това какви права/привилегии действат при маунтване на туй онуй - значи има права на device, има права на mount-point-а, евентуално има права вътре в самата файлова система (ако е linux).
Също така искам да питам ако искаме да си направим директория в която всички да мажат, и да гледат и останалите какво са намазали какви да са опциите. На федора директориите със set-group-id форсват групата на директорията в корена да се мултиплицира върху новосъздадени директории вътре, но първо мисля че това е red-hat поведение (защото не го пише в man page-а) и второ какво става като повечето user-и имат настроен umask=0002, което прави групата с недостатъчни привилегии. Със sticky-bit-а не става защото един като направи нещо, другите не могат да го трият, а аз искам да може всеки да маже съвсем свободно (всеки, от някаква определена група примерно).

Не мога да кажа с голяма сигурност но някакво вътрешно чувство ми подсказва, че имаш проблеми с видеокартата. Виж в менюто

System->Administration->Hardware Drivers

Ако има някакви неинсталирани драйвери - инсталирай ги. Ако няма ... тогава става малко сложно - потърси във интернет дали други хора с твоята карта имат подобни проблеми, току виж някой ентусиаст е написал няколко магически команди за xorg.conf които да разрешават проблема

VLC-то от сорс ли си го инсталирал или от репо. Аз лично пробвах да го инсталирам от сорс, половин час се занимавах да му инсталирам депендънсита, после се компилира цяла вечност, и в крайна сметка беше леко бъгаво. На убунту го има в репото и се държи сравнително добре, и все пак препоръчвам да ползваш mplayer или xine (вместо да инсталираш vlc от сорс).

Здравейте отново,

От около месец вече съм писал в mail листите на cups / samba и от там няма никакъв отговор. Навсякъде се разправя, че самбата била най-добре документирания опън проект и имало супер много хелп навсякъде, само аз ли не мога да го намеря?

Има ли някакъв начин да пусна cups във по-verbose режим за да се види къде по веригата се чупи нещо?
Има ли начин да пусна samba в по-verbose режим за да се види поне нещо когато печатам документ?

Според логовете на къпс, всичко е минало успешно (може да видите в първия пост). Къде мога да видя какво е станало с документа след като според cups едва ли не той е изпечатан?

[about:config]

Мерси на всички отговорили!

@vstoykov - маргините са по дефоулт, даже пробвах да сложа огромен горен маргин - без особен резултат (т.е без никакъв резултат)
@nov_chovek  - във firefox не може да се изибра размер хартията (поне при мен) - има само вид (normal, bond, card stock ...). Аз обаче чак сега се сетих и : от about:config настроих print.postscript.paper_size на A4 и вече поне ми излизат първите редове... обаче пак са твърде високо.

Печатам в ps, след което слагам на 100%. Когато наложа страницата върху монитора е 1:1. Текста на страницата абсолютно съвпада с текста на монитора. И пак започва с около 2 сантиметра по-нагоре, от колкото трябва. Нямам линиика да измеря точно колко е, но мисля че нещо постскриптския документ не се изпраща като хората към принтера. Защото ако изпечатам първо в pdf на пръв поглед изглежда абсолютно същото (т.е визуално, на монитора изглеждат еднакви документите), обаче като го изпечатам (вече pdf-а) първият ред си започва от където трябва - т.е като наложа страницата върху монитора е (почти) перфектно.

Има такава отметка - Ignore scaling and shrink to fit page width. Пробвах с и без нея - без особен резултат. То при мен по-скоро проблема е по дължина. Тъпото е че дъното на страницата стои празно (т.е очевидно слага твърде нагоре content-a и затова долу стой празно).

Здравейте,

Имам вързан xerox phaser 3117 към щайгата ... и като цяло се държи добре. Сложил съм драйвери за Samsung ML-1710 (както пише в OpenPrintingDatabase). Когато печатам през firefox-a началото на всяка страница е изрязано - т.е софтуера се опитва да сложи страницата твърде високо (даже мисля над самия лист) и понеже принтера не може да печата по абсолютно целия лист не се вижда първия ред. Интересното е че print preview-то изглежда доста добре, даже принтирано в PS пак изглежда добре, но даже когато дам PS-файла да се изпечата пак ми изяжда първия ред. Сега забелязах, че ако принтирам PS-файла до PDF и после изпечатам PDF-а тогава се държи добре (т.е слага нормални граници и всичко ок).

Значи въпроса ми е защо по дяволите в kghostview-то документа изглежда нормално, но след изпечатване се изрязват първите няколко сантиметра, но ако предварително изпечатам файла във pdf и след това изпечатам pdf-a всичко е ок. Мисля че съм настройл големината на страницата правилно, колкото до margin-ите - каквото и да слагам там няма никакъв ефект.

Ползвам cups версия 1.3.7, ghostscript 8.61.

[Решение 1]

Да обобщя:

Като тръгна да свалям плъгини през файърфокса, ми дава грешка -228 (проблеми с връзката).
Като пробвам да го сваля плъгина през wget ако не дам допълнителна опция става това:

$ wget --verbose 'https://addons.mozilla.org/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi'
--04:39:09--  https://addons.mozilla.org/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi
           => `java_console_6.0.00-6.0-fx.xpi'
Resolving addons.mozilla.org... 63.245.209.120
Connecting to addons.mozilla.org|63.245.209.120|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://addons.mozilla.org/en-US/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi [following]
--04:39:16--  https://addons.mozilla.org/en-US/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi
           => `java_console_6.0.00-6.0-fx.xpi'
Connecting to addons.mozilla.org|63.245.209.120|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://addons.mozilla.org/en-US/firefox/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi [following]
--04:39:23--  https://addons.mozilla.org/en-US/firefox/downloads/file/18717/java_console_6.0.00-6.0-fx.xpi
           => `java_console_6.0.00-6.0-fx.xpi'
Connecting to addons.mozilla.org|63.245.209.120|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://releases.mozilla.org/pub/mozilla.org/addons/5577/java_console_6.0.00-6.0-fx.xpi [following]
--04:39:31--  http://releases.mozilla.org/pub/mozilla.org/addons/5577/java_console_6.0.00-6.0-fx.xpi
           => `java_console_6.0.00-6.0-fx.xpi'
Resolving releases.mozilla.org... failed: Message too long.

преди стигаше до resolve на releases.mozilla.org, което връщаше IPv6 по незнайна причина, но сега въща това.

само да вметна, че dir/nslookup при подаден releases.mozilla.org връщат няколко IP-та всичките от които са v4, ако се използва командата host излизат и 3 IPv6 IP-та, които бъркат в здравето - и 3те не работят (вероятно сървърите отзад не си вършат работата като хората)

Разрових се из разни форуми итн, някой предлагат да се хардкодне IP-то на съответния хост във /etc/hosts, но според мен това е само замазване на положението. Съществува и варианта проблема да не е в линукса, а в DNS сървърите, защото в http://ubuntuforums.org/showthread.php?t=587533 тема се казва нещо подобно на втората страница (и се аргументира).

Решение 1 - добавя се следния ред във /etc/hosts:

64.50.236.52    releases.mozilla.org

Отрицателни страни - ако след време някой друг вземе ip-то и сложи 'лоши' неща на него е вероятно да ви скапе firefox-а ако не и нещо по лошо - затова трябва периодично да проверявате дали това IP отговаря на releases.mozilla.org.

Решение 2 - забранявате IPv6 във firefox. Това става от страницата 'about:config' промените долната опция на true:

network.dns.disableIPv6 ---> true

Отрицателни страни - няма да може да влизате в сайтове които са на съвръри използващи IPv6 - за сега не знам дали има много такива но в бъдеще е вероятно да стават повече

Решение 3 - плъгините се свалят ръчно (със wget -4, за да му се забранява да ползва IPv6). Адреса на плъгина може да видите от файърфокса, малко преди да започне самото сваляне - copy paste в конзолата и го wget-вате. След което влачите сваления файл в прозореца за add-on-ите и ff-то се оправя само
Отрицателни страни - малко или много е неудобно. Ако сте hard-core фен, който обича да виси по конзолите е ок

Също така остава проблема със nscd (който няма абсолютно никаква връзка с горния), който дава следната грешка при опит за старт:

Starting nscd: /usr/sbin/nscd: relocation error: /usr/sbin/nscd: symbol __nss_services_lookup, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
                                                           [FAILED]

Аха.. значи форсваме IPv4. Обаче това не решава проблема с firefox

[Забележка]

Аз съм с маалко по-стара федора и при мен xchat-а се пуска с ...

$ xchat

Иначе може да проваш да изтеглиш програмата от официалния сайт http://www.xchat.org/download/, да компилираш и инсталираш (трябва да има README/INSTALL файл с повече указания вътре).

Забележка: възможно е да има и много по-културно решение на въпроса - не претендирам, че това е най-добрия начин, но е доста вероятно ръчната инсталация да даде резултат.

Забележка2: сякаш това е някакъв бъг (вече рапортуван където трябва), така че на първо време слагай нормалния xchat по старомодня начин и следи тук https://bugzilla.redhat.com/show_bug.cgi?id=478649 примерно да видиш дали има развитие. Също има вероятност да имаш пакет xchat, който да може да инсталираш директно през yum:

# yum install xchat

Първо пробвай тaка, после, ако го няма, от официалния сайт!

Успех

; generated by /sbin/dhclient-script
nameserver 94.26.50.7
nameserver 94.26.50.8

Ето /etc/resolv.conf - тоя файл не е пипан от хилядолетия. Колкото до nscd - усетих че няма много връзка щом е спрян, и все пак има проблем с пускането му (явно 2 съвсем не свързани проблема)

$ dig releases.mozilla.org

; <<>> DiG 9.5.0-P2 <<>> releases.mozilla.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7229
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;releases.mozilla.org.          IN      A

;; ANSWER SECTION:
releases.mozilla.org.   60      IN      CNAME   releases.geo.mozilla.com.
releases.geo.mozilla.com. 60    IN      A       64.50.236.52
releases.geo.mozilla.com. 60    IN      A       64.50.236.214
releases.geo.mozilla.com. 60    IN      A       64.50.238.52
releases.geo.mozilla.com. 60    IN      A       128.61.111.9
releases.geo.mozilla.com. 60    IN      A       129.101.198.59
releases.geo.mozilla.com. 60    IN      A       131.188.12.212
releases.geo.mozilla.com. 60    IN      A       149.20.20.5
releases.geo.mozilla.com. 60    IN      A       155.98.64.83
releases.geo.mozilla.com. 60    IN      A       156.56.247.196
releases.geo.mozilla.com. 60    IN      A       202.177.202.154
releases.geo.mozilla.com. 60    IN      A       204.152.184.113
releases.geo.mozilla.com. 60    IN      A       204.152.184.196
releases.geo.mozilla.com. 60    IN      A       204.246.0.136
releases.geo.mozilla.com. 60    IN      A       216.165.129.141

;; AUTHORITY SECTION:
releases.geo.mozilla.com. 211900 IN     NS      ns1.geo.mozilla.com.
releases.geo.mozilla.com. 211900 IN     NS      ns0.geo.mozilla.com.

;; ADDITIONAL SECTION:
ns0.geo.mozilla.com.    211900  IN      A       63.245.208.22
ns1.geo.mozilla.com.    211900  IN      A       63.245.212.22

;; Query time: 100 msec
;; SERVER: 94.26.50.7#53(94.26.50.7)
;; WHEN: Tue Feb  3 02:51:02 2009
;; MSG SIZE  rcvd: 368

Не разбирам... не виждам никъде IPv6, със nslookup е нормално, със това dig също изглежда като твоето

::edit:: сортирах 2та списъка с ип-та и са абсолютно еднакви... някаква идея защо има проблем при wget-a. Освен това в hosts нямам абсолютно никакви записи свързани с мозила (има 3 други реда, които са за други сървъри + още 2 за localhost).

Търсачката се счупи за 1-2 часа и веднага почнаха някакви гневни постове насочени към компанията... Това е една от малкото големи корпорации, които мислят за user-ите като хора, а не като банкови сметки. Който не се кефи на търсачката - просто да не я полза. Оборота щял да падне ако сайта е маркиран като опасен... ами ако въобще нямаше гуугъл от къде щеше да идва оборота?? Монополист е на пазара защото предоставя най-доброто, а не защото хората са свикнали и са навътре с хиляди долари и документи (какъвто е случая с microsoft), също прави качествени продукти и печели пари от големи корпорации, а не от крайни потребители. И тази защита за 'опасни' сайтове не вярвам да са си я смукали от пръстите - 100% е имало хора, оплакали се че като цъкнат на линк след търсене са се заразили ... то е за добро! До сега не съм видял техен ход, който да е насочен към влошаване на качеството по някакъв начин, преебаване на клиента с цел изгода в тяхна полза. Колкото до спам филтъра ... ами аз не съм видял досега поща/клиент който не поддържа неговото махане. Който иска да чете на ден по 100 реда с глупости всеки ден и да отсява важното - негова си работа, защо трябва да се плюе по самия филтър.

Наздраве на всички и да живее google