Prosíme přihlašte se nebo zaregistrujte.

Přihlašte se svým uživatelským jménem a heslem.
Blog Ubuntu -- Správa "projektů" české komunity Ubuntu

Novinky: Školení nejen k OS Ubuntu pro širokou veřejnost, více informací zde.

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - GdH

Stran: [1] 2 3 ... 116
6
Nameday applet jsem bohužel pro GNOME Shell nepřepsal, ale sám ho v něm léta používám přes rozšíření (K)StatusNotifierItem/AppIndicator Support), ovšem v Ubuntu do verze 16.04.
Takže možný pokus pro tuto chvíli je přidat si zmíněné rozšíření do GS, stáhnout z mého ppa poslední verzi Nameday indikátoru (64 bit, 32 bit) a pak zkusit nainstalovat a spustit. Pokud to poběží, může se objevit problém s formátováním seznamů a zaznamenal jsem i pád Shellu při otevření okna vyhledávání, ale svátky ukazuje. Snad se někdy utrhnu a zkusím to naroubovat přímo na GS a aktualizovat seznam svátků...

7
Zkus kouknout sem na poslední odstavec části Další práva, jestli je to to, co potřebuješ.

8
Napsal jsem čtyři věty. Třetí jsi zřejmě přehlédl úplně, druhou nepochopil.

9
Jestli v tom skriptu za then nic nedáš, tak shell neočekává elif a skončí chybou. Je celkem logické, že když nepotřebuješ zjišťovat stav "pre", tak ho netestuješ. Také je v dashi třeba používat jednoduché rovnítko při porovnávání řetězců, i když bash akceptuje dvojité i v jednoduchých hranatých závorkách. Jinak jsou ty dva skripty identicky nesmyslně komplikované.

10
Pomoc s hardwarem / PŘESUNUTO: Zahltí se mi RAM paměť (6 GB)
« kdy: 10 Květen 2018, 21:43:11 »

11
Obecná podpora / PŘESUNUTO: Nejde spustit Steam
« kdy: 08 Květen 2018, 17:38:39 »

12
Podpora pro pracovní prostředí / Re:Změna velikosti okna
« kdy: 15 Duben 2018, 10:47:16 »
Pokud velikost okna nejde přizpůsobit myší, tak s tím nic neuděláš, je to kombinace toho, jak je napsané okno a použitého tématu vzhledu (to má vliv na velikost jednotlivých prvků).

13
Podpora pro pracovní prostředí / Re:Firefox - načítání
« kdy: 13 Duben 2018, 16:05:44 »
Já to vyřešil jednoduše - vymazal jsem cookies idnes.cz a je po problému.
Jinak toto varování považuji za velmi užitečné, protože pokud nějaká webová stránka sebere výkon celému systému, alespoň se o tom hned dozvím a můžu to řešit.

14
Tak ještě nějaké upřesnění. Nautilus ukládá změny výchozích aplikací pro mime typy jen do souboru
Kód: [Vybrat]
~/.config/mimeapps.lista ten je pro něj výchozím. Při prvním otevření souboru Nautilus kouká ještě do všech následujících mime databází v tomto pořadí (Ubuntu 16.04):
Kód: [Vybrat]
~/.local/share/mime/mime.cache
~/.local/share/applications/mimeapps.list
~/.local/share/applications/defaults.list
~/.local/share/applications/mimeinfo.cache
/etc/gnome/defaults.list
/usr/local/share/applications/defaults.list
/usr/local/share/applications/mimeinfo.cache
/usr/share/applications/defaults.list
/usr/share/applications/mimeinfo.cache

mimeopen ~/.config/mimeapps.list ignoruje a změny zapisuje pouze do
Kód: [Vybrat]
~/.local/share/applications/defaults.list
Protože jsi spouštěl Nautila přes sudo, přepsal sis stoprocentně vlastníka některých souborů v $HOME na roota. Pokud uživatel vlastní nadřazený adresář, práva na soubor mu i přes změnu vlastníka zůstanou a při dalším zápisu (aplikace bez sudo) se to vrátí zpět. Jak ale root sáhne i na nadřazený adresář, má uživatel smůlu a do souboru už nic nezapíše. Proto se při spuštění grafických aplikací přes holé sudo většinou nestane nic, čeho by si uživatel všiml. Každopádně používat holé sudo na Nautila a jakoukoli jinou uživatelskou aplikaci, která má soubory v $HOME, je nebezpečné a když už člověk musí něco takového udělat, tak přepínač -i za sudo udělá login do shellu roota a změní patřičně proměnnou $HOME, aby si root zapisoval do svého.

15
Podpora pro pracovní prostředí / Re:Firefox - načítání
« kdy: 08 Duben 2018, 14:18:47 »
To není o čekání, ale o tom, že něco dlouhodobě vytáčí cpu na maximum. Je otázka, co za tím je, protože v základním okně se mi na tom FF sekne, kdežto v anonymním ne.

16
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 03 Duben 2018, 21:50:51 »
sudo kesuje ve vychozim stavu na iirc 10 nebo 15 minut heslo ... to je zlo jako svine .. ;)

Když si otevřeš terminál přes su a timeout nemáš žádný, jaký je v tom pro tebe bezpečnostní benefit? Navíc sudo platí pouze pro jeden příkaz a další potřebuje další sudo, i když do timeoutu bez hesla.

17
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 03 Duben 2018, 16:42:16 »
....

rozhodne neprevazuji podle meho nazoru .. prevazovaly by, ale ne na typicke workstation, kde ti pod stejnym uzivatelem bezi napr. prohlizec a nebo (casto) proprietalni *censored* jako hry ze steamu, skype a kdovi co jeste napr. pod wine apod ... alespon podle meho nazoru

to, ze se sudo pouziva jako vychozi snad jen kvuli tomu, aby nebylo mozny bruteforcovat heslo na roota, je relikt s nepochopitelnejma a iracionalnima zakladama ...

ps. me trvalo asi tak 15 let linuxovani nez jsem pochopil, ze bezici sshd na my workstation je naprosta ptakovina ;)

Takový uživatel má sice možnost použít sudo, ale bez hesla nemá žádná práva navíc, oproti uživateli bez sudo a ty aplikace se k heslu sudoera přeci nedostanou jednodušeji, než k heslu roota. Pokud by uživatel začal používat účet roota, který má od přírody všechna práva vždy, rozhodně bych to neviděl jako minimalizaci rizik. Důvody, proč sudo ano a ne, jsou vypsány třeba zde: https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo , klidně nám ntz napiš další postřehy, které tam nejsou.

18
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 02 Duben 2018, 11:24:11 »
@GdH
Ale myslím, že tohle je dost nebezpečné, ne?
Kód: [Vybrat]
#%sudo   ALL=(ALL:ALL) ALLJe to pro všechny. Či mám odkomentovat?

Ten řádek dává právo používat příkaz sudo pouze uživatelům, kteří patří do skupiny sudo. Běžně se uživatelé, kteří mají mít toto právo, přidávají do této skupiny, místo aby se kvůli nim přepisoval sudoers.


...
ja osobne defaultni ubunti model se sudo, kdy nezadavas heslo roota ale heslo obycejneho uzivatele, povazuju za naprostej blaznivej a jeste mnohem vic nebezpecnej *censored*, nez mit nastaveno separatni heslo na roota ...

Já bych řekl, že výhody zásadně převažují, zvláště na systému pro obyčejné uživatele :)

19
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 01 Duben 2018, 15:22:48 »
Správnějším řešením je uživatele vik přidat do skupiny sudo, která má v sudoers již garantována práva.
Kód: [Vybrat]
usermod -a -G sudo vikJinak mezi výchozí skupiny admina v ubuntu patří tyto (příklad výpisu pro mého uživatele):
Kód: [Vybrat]
gdh@gdh:~$ groups gdh
gdh : gdh adm cdrom sudo dip video plugdev lpadmin sambashare systemd-journal
U verze 14.04 si nejsem jist jen skupinou systemd-journal.

Ty řádky s thunderbirdem bych řekl, že nebudou fungovat..

20
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 01 Duben 2018, 13:50:43 »
Já to nepsal jako návod, ale jako info, abys pochopil, proč se to chová tak, jak se to chová a doufal jsem, že si všechny ty informace poskládáš sám.

Jak má vypadat soubor /etc/sudoers sis tu vypsal sám, tvrdil jsi, že je to obsah souboru visudo. Z toho vyplývá, že sis sudoers nejspíš jednoduše přejmenoval. Pak jsi vložil i výchozí verzi sudoers, kam jsi ale zjevně připsal nesmyslný řádek s výpisem příkazu ls -l.

Ntz ti ukázal, jak mají vypadat práva /etc/sudoers, já ti napsal, jak toho docílíš.

Další info.
Soubor /etc/sudoers obecně obsahuje pravidla pro chování příkazu sudo a umožňuje, mimo jiné, i povolit použití sudo bez nutnosti zadávání hesla v konkrétních případech, jak jsi naznačil. Bez tohoto souboru sudo nemůže vůbec fungovat a tudíž tam byl už od instalace systému.

/etc/sudoers.d je adresář, kam se dají dopisovat další pravidla do samostatných souborů a pokud je v sudoers patřičný řádek s příkazem includedir, importují se tato pravidla také, jako by byla zapsána přímo v /etc/sudoers. Ve výchozím stavu se ale tento adresář nevyužije, protože je řádek s importem v sudoers zakomentován.

21
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 01 Duben 2018, 11:22:52 »
su samotné (ne)funguje správně, se sudoers nemá nic společného a vyžaduje heslo roota, který v ubuntu ve výchozím stavu jako klasický uživatel neexistuje a existovat nemá. Je možné su použít právě se sudo, nebo pkexec, ale v podstatě to nedává smysl, protože oba příkazy umí to samé i bez su, s patřičným přepínačem.

Příkaz pkexec je určen k tomu samému, co sudo a bude fungovat, i když je /etc/sudoers poškozen, protože jeho nastavení definuje úplně jiná sada pravidel založená na PolicyKit.


22
Podpora pro pracovní prostředí / Re:sudo su nekomunikuje
« kdy: 31 Březen 2018, 20:31:33 »
Docela by mě zajímala historie tvého bashe, k takové prasárně nedojde jen tak a soubor visudo s obsahem sudoers sis musel sám vytvořit. visudo je příkaz, kterým se sudoers edituje, umí totiž oproti běžnému editoru kontrolovat správnost syntaxe, což je u tohoto souboru velmi užitečné ze stejného důvodu, který se tu řeší.

Ten řádek z výstupu ls -l, který poslal ntz, ukazuje správné nastavení práv /etc/sudoers, ne řádek, kerý máš přidat. Pokud má soubor špatně nastavená práva, nebude sudo z bezpečnostních důvodů fungovat. Správná práva lze nastavit buď příkazem:
Kód: [Vybrat]
pkexec chmod 0440 /etc/sudoersnebo postaru bootem do recovery módu, připojením systémového disku pro zápis a spuštěním stejného příkazu bez pkexec.

Otázkou je, zda nemají poškozená práva i další systémové soubory a pokud to nemáš pod kontrolou, může být reinstalace systému rozumné řešení.

Stran: [1] 2 3 ... 116