25
lutego
2010
Pomimo udostepnienia drukarki, dostepu sieciowego itp, cups nie drukuje na udostepnione urzadzenie. W logach jest komunikat
NT_STATUS_LOGON_TYPE_NOT_GRANTED .
Rozwiazanie jest ... "proste". Na komputerze z windows nalezy zrobić
[start] -> uruchom -> secpol.msc
opcję ustawienia zabezpieczen ->
zasady lokalne ->
opcje zabezpieczen ->
dostep sieciowy; udostepnianie i model zabezpieczen dla kont lokalnych
ustawić na "klasyczne"
Działa natychmiast od momentu ustawienia, a wymaga ponad godziny szukania. Dlaczego ten system jest taki nieintuicyjny?
20
lutego
2010
Od niedawna jeżdzę na wdrożenia do sklepów w których średnia ilość komputerów zdecydowanie przekracza 20. W centrum tego majdanu jest linuksowy serwer, reszta komputerów jest na windows.
Zadanie - skonfigurować drukarki laserowe z całego sklepu na serwerze. Klikanie w cups doprowadzić może do szału, dlatego lepiej je sobie odpuścić. Samo wyszukanie drukarki trwa wieki w interfejsie www cups i raczej nie da się klonować drukarek. Dlatego zacząłem szukać innego rozwiązania.
Procedura jest prosta - mamy drukarkę samodzielną (sieciową) - ustalamy model i adres ip.
Mamy drukarkę usb/lpt przy komputerze windowsowym - udostępniamy, zapisujemy login i hasło do komputera oraz nazwę udziału i model drukarki. To najbardziej czasochłonna (i nieunikniona) faza.
pierwszy wpis do /etc/cups/printers.conf :
<DefaultPrinter drukarka-1>
Info opis
AuthInfoRequired none
DeviceURI [adres]
State Idle
StateTime 1249546106
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
Option orientation-requested 3
</Printer>
gdzie w miejsce [adres] dajemy
smb://uzytkownik:haslo@gruparobocza/komputer/drukarka
lub
smb://uzytkownik:haslo@adresip_komputera/drukarka
w przypadku udostepnionej drukarki
lub
socket://ip_drukarki:9100
w przypadku drukarki sieciowej HP ( port moze byc inny przy urzadzeniach innych producentow ).
szukamy odpowiedniego sterownika w /usr/share/cups/model i rozpakowujemy do /etc/cups/ppd/drukarka-1.ppd (nazwa taka sama jak nazwa drukarki w cups).
teraz wystarczy restart cups i puszczenie strony testowej ( /usr/share/cups/data/testprint.ps ) za pomoca lpr na wybrana drukarke.
W przypadku konfigurowania kolejnych drukarek wystarczy kopiowac cala poprzednia sekcje DefaultPrinter, tym razem pomijajac slowo "Default" . nalezy zmienic adres urzadzenia i nazwe drukarki. Po czym nalezy w /etc/cups/ppd umiescic plik .ppd o nazwie odpowiadajacej nazwie wprowadzonej drukarki.
W przypadku konfiguracji 30 identycznych drukarek mozna w ten sposob zaoszczedzic mnostwo czasu. Klikanie w interfejsie cups lub roznych konfiguratorach jest jednak zbyt czasochlonne i nie zostalo przygotowane z mysla o takiej sytuacji :]
04
lutego
2010
Od dzisiaj w moim miejscu pracy (helpdesk) pojawily sie nowe wytyczne.
Kiedy klient zglasza problem w systemie zgloszen (A) nalezy zarejestrowac zadanie w drugim systemie zgloszen (B), na ktorym nalezy rejestrowac swoj czas pracy nad wlasciwym zgloszeniem od klienta (uzywane przy rozbijaniu kosztow pracy kazdego pracownika na poszczegolne projekty). Zeby nie bylo nudno, gdy wymagana jest interwencja programisty nalezy mu napisac kolejne zadanie w systemie B.
W przypadku platnej uslugi nalezy w systemie A przy zgloszeniu zarejestrowac wycene, poczekac na akceptacje klienta, po czym w trzecim systemie ksiegowym (C) odnotowac platna usluge. Kiedy juz to wszystko zrobimy mozemy to wszystko pozamykac i popotwierdzac.
Dodatkowe uwagi -
W ten sposob problem ktory mozna klientowi rozwiazac w ~5 minut wymaga co najmniej 30 minut klikania w rozmaitych systemach. W przypadku platnej uslugi czas rozciaga sie o dodatkowe 30 minut, ze wzgledu na "wydajnosc" systemu ksiegowego. Nie uwzglednilem oczywiscie czasu realizacji prac programistow i negocjacji z klientem.
Mysle ze czas najwyzszy szukac nowej pracy, bo nie wiem jak bedzie wygladac kolejna iteracja tego mechanizmu.
14 września 2011, 22:19:53 | klucz ssh na gitorious |
Od niedawna przyłapałem się na tym że na gitorious.org przestał działać mój klucz ssh. Próba ponownej instalacji klucza powodowała jego odrzucanie ( " ssh key invalid " ).
Problem polega na tym ze zamiast user@host na końcu klucza trzeba wpisać swój email jaki podaliśmy przy rejestracji w gitorious.org. Być może problem nie dotyczy wszystkich, ale u mnie było to jedyne działające rozwiązanie.
04 lipca 2011, 12:48:34 | Tunelowanie esx po ssh |
Szybka notatka na przyszłość; aby wbić się na serwer ESX za pomocą vSphere poprzez tunel SSH, trzeba przeforwardować porty 443, 902, 903 oraz dodać wpis do hosts postaci
127.0.0.1 esxhost
bez tego nie pójdzie. Posiadanie wpisu określającego 127.0.0.1 jako "localhost" też z jakiegoś powodu nie wystarcza i dostaje się tajemnicze informacje o nieprawidłowym hoście, braku łączności itp.
02 sierpnia 2010, 20:12:02 | [mini] nietypowy problem CUPS |
ERRDOS - ERRbadaccess (Invalid open mode.) opening remote spool Test Page
W takiej sytuacji należy w windows w wlaściwościach drukarki odznaczyć "drukuj bezpośrednio na drukarkę". Dziwne, ale zostawię to sobie tutaj na przyszłość.