Differences between revisions 2 and 3
Revision 2 as of 2008-07-08 05:24:15
Size: 9455
Comment:
Revision 3 as of 2008-07-08 06:00:02
Size: 9679
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Другие конфигураторы с web-интерфейсом
Как говорилось в прошлых лекциях универсальный конфигуратор эффективен только в двух случаях: 1)Он разрезан на модули 2) Он
имеет довольно большую команду разработчиков. В случае если мы имеем отдельную, выделенную подсистему, которая не сильно
завязана на все остальные параметры нашей операционной системы, вполне возможно создание для неё выделенного
конфигуратора,
эта задача еще больше упрощается если о создании такого конфигуратора позаботились разработчики этой
подсистемы . Типичный пример, который мы рассматривать не будем --- это веб-движки, большинство из которых представляют
собой большое количество кода написанное
например на PHP, который потом подкладывается в определенные места, после чего
они запускаются и все административная деятельность по управлению ими происходит через их же собственный интерфейс.
Например так устроен Друпал?? - вы скачиваете некий файл на PHP, подготавливаете MySQL, дальше при попытке зайти в него он
обнаруживает что он не установлен, устанавливается, после чего в нем можно включить его же собственные модули, скачать
новые модули. Другой вариант, когда авторы некой подсистемы предусмотрели некий графический интерфейс своей подсистемы и
её распространяют вместе. В таком случае часто вместо того чтобы пытаться переписать эту функциональность, бывает проще
подогнать его
под условия ОС и\или конкретного дистрибутива. Так например не имеет большего смысла переписывать на
Sheme??? функциональность конфигуратора CUPS с целью интеграции его в Альтератор, когда она и так довольно хороша и
неплохо поддерживается разработчиками.
Устроенна она примерно также как веб-интерфейс Альтератора- т.е. на определенном порту есть некий веб-сервис,
подсоединившись к которому по http вы можете легко им управлять. Причём, в отличие от Альтератора, где сразу надо получить
права суперпользователя, в веб-интерфейсе CUPS довольно большое количество интерфейса доступно обычному пользователю(не
представившегося системе), либо пользователю со своим логином и паролем.- например возможность снять собственные задания.
Сервер печати по умолчанию запускается на каждой машине, а не только на той, на которой есть принтер. Это происходит по
следующим причинам. CUPS написан так, что при определенных настройках администратором, он может рассылать по своему
собственному протоколу сообщения о доступности принтера. Поэтому, если вы делаете доступным сетевой принтер в локальной
сети т.е. разрешаете делать его видимым(т.е. рассылать вышеупомянутые сообщения), то при установленной CUPS любой клиент
может этим воспользоваться. Естественно, принтером можно воспользоваться и без этого, но тогда надо самостоятельно писать
различные модули, что , в общем, представляет собой не очень приятное занятие. Что же касается CUPS, то это достаточно
сложный программный продукт, управление которым не будет освящаться от начала до конца.  Достаточно сказать что он,
например, эксплуатируется на таких многоранговых сетях, где есть не только несколько принтеров, но где существуют
несколько классов принтеров. Например часть пользователей имеет право печатать на всех принтерах, а часть - только на
принтерах какого-то определенного класса. В большинстве случаев никто такой сложной системой не пользуется. Быстро
пробежимся настройкам.
Если вы находитесь на клиенте и на сервере настроен CUPS принтер, то настройки лучше не трогать.
Если сидите на клиенте, а сервер не настроен (например, виндовый сервер с расшаренным по smb принтером), то можно написать
его локатор.

Как говорилось в прошлых лекциях универсальный конфигуратор эффективен только в двух случаях:
 *
Он разрезан на модули
 *
Он имеет довольно большую команду разработчиков.
В случае если мы имеем отдельную, выделенную подсистему, которая не сильно завязана на все остальные параметры нашей операционной системы, то вполне возможно создание для неё выделенного конфигуратора. Эта задача еще больше упрощается если о создании такого конфигуратора позаботились разработчики этой подсистемы . Типичный пример, который мы рассматривать не будем --- это системы управления сайтом(CMS), большинство из которых написанны на например на PHP, их исходный код потом подкладывается в определенные места, после чего они запускаются и все административная деятельность по управлению ими происходит через их же собственный интерфейс. Например так устроен Drupal - вы скачиваете некий файл на PHP, подготавливаете   БД SQL, дальше при попытке зайти в него он обнаруживает что он не установлен, устанавливается, после чего в нем можно включать его же собственные модули, скачивать новые и т.п.

Другой вариант, когда авторы некой подсистемы предусмотрели к ней некий графический интерфейс и распространяют их вместе. В таком случае часто, вместо того чт
обы пытаться заново переписать эту функциональность, бывает проще подогнать имеющийся конфигуратор под условия ОС и\или конкретного дистрибутива. Так например не имеет большего смысла переписывать на Scheme функциональность конфигуратора CUPS(Common Unix Printing System - сервер печати) с целью интеграции его в Альтератор, т.к. она и так довольно хороша, и к тому же неплохо поддерживается разработчиками.
===Устройство конфигуратора CUPS
Устроен он
примерно также как веб-интерфейс Альтератора- т.е. на определенном порту есть некий веб-сервис,
подсоединившись к которому по http вы можете легко  управлять сервером печати. Причём, в отличие от Альтератора, где сразу надо получить
права суперпользователя, в веб-интерфейсе CUPS довольно большое количество действий и настроек доступно обычному пользователю(не
представившемуся системе), либо пользователю  вошедшему со своим логином и паролем.- например возможность снять собственные задания.

Сервер печати (по умолчанию??'в альт-линуксе?') запускается на каждой машине, а не только на той, на которой есть принтер. Это происходит по следующим причинам. CUPS написан так, что при определенных настройках администратором, он может рассылать по своему собственному протоколу --- IPP --- сообщения о доступности принтера. Поэтому, если вы делаете доступным сетевой принтер в локальной сети т.е. разрешаете делать его видимым(т.е. рассылать вышеупомянутые сообщения), то при установленной CUPS любой клиент может этим воспользоваться. Естественно, принтером можно воспользоваться и без этого, но тогда надо самостоятельно писать различные модули, что , в общем, представляет собой не очень приятное занятие.

Что же касается CUPS, то это достаточно сложный программный продукт, управление которым не будет освящаться от начала до конца. Достаточно сказать что он, например, эксплуатируется на таких многоранговых сетях, где есть не только несколько принтеров, но где существуют несколько классов принтеров. Например часть пользователей имеет право печатать на всех принтерах, а часть - только на принтерах какого-то определенного класса. В большинстве случаев,однако, никто такой сложной системой не пользуется.

Быстро пробе
жимся настройкам:
 1
.Если вы находитесь на клиенте и на сервере настроен CUPS принтер, то настройки лучше не трогать.
 2.''Если сидите на клиенте, а сервер не настроен (например, виндовый сервер с расшаренным по smb принтером), то можно написать его локатор.
Line 41: Line 29:
Эта часть придет позже - ArtemSerebriyskiy''
Line 56: Line 45:
|| 10 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]] || || || || 15 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]] || || ||

Другие конфигураторы с web-интерфейсом

Как говорилось в прошлых лекциях универсальный конфигуратор эффективен только в двух случаях:

  • Он разрезан на модули
  • Он имеет довольно большую команду разработчиков.

В случае если мы имеем отдельную, выделенную подсистему, которая не сильно завязана на все остальные параметры нашей операционной системы, то вполне возможно создание для неё выделенного конфигуратора. Эта задача еще больше упрощается если о создании такого конфигуратора позаботились разработчики этой подсистемы . Типичный пример, который мы рассматривать не будем --- это системы управления сайтом(CMS), большинство из которых написанны на например на PHP, их исходный код потом подкладывается в определенные места, после чего они запускаются и все административная деятельность по управлению ими происходит через их же собственный интерфейс. Например так устроен Drupal - вы скачиваете некий файл на PHP, подготавливаете БД SQL, дальше при попытке зайти в него он обнаруживает что он не установлен, устанавливается, после чего в нем можно включать его же собственные модули, скачивать новые и т.п.

Другой вариант, когда авторы некой подсистемы предусмотрели к ней некий графический интерфейс и распространяют их вместе. В таком случае часто, вместо того чтобы пытаться заново переписать эту функциональность, бывает проще подогнать имеющийся конфигуратор под условия ОС и\или конкретного дистрибутива. Так например не имеет большего смысла переписывать на Scheme функциональность конфигуратора CUPS(Common Unix Printing System - сервер печати) с целью интеграции его в Альтератор, т.к. она и так довольно хороша, и к тому же неплохо поддерживается разработчиками. ===Устройство конфигуратора CUPS Устроен он примерно также как веб-интерфейс Альтератора- т.е. на определенном порту есть некий веб-сервис, подсоединившись к которому по http вы можете легко управлять сервером печати. Причём, в отличие от Альтератора, где сразу надо получить права суперпользователя, в веб-интерфейсе CUPS довольно большое количество действий и настроек доступно обычному пользователю(не представившемуся системе), либо пользователю вошедшему со своим логином и паролем.- например возможность снять собственные задания.

Сервер печати (по умолчанию??'в альт-линуксе?') запускается на каждой машине, а не только на той, на которой есть принтер. Это происходит по следующим причинам. CUPS написан так, что при определенных настройках администратором, он может рассылать по своему собственному протоколу --- IPP --- сообщения о доступности принтера. Поэтому, если вы делаете доступным сетевой принтер в локальной сети т.е. разрешаете делать его видимым(т.е. рассылать вышеупомянутые сообщения), то при установленной CUPS любой клиент может этим воспользоваться. Естественно, принтером можно воспользоваться и без этого, но тогда надо самостоятельно писать различные модули, что , в общем, представляет собой не очень приятное занятие.

Что же касается CUPS, то это достаточно сложный программный продукт, управление которым не будет освящаться от начала до конца. Достаточно сказать что он, например, эксплуатируется на таких многоранговых сетях, где есть не только несколько принтеров, но где существуют несколько классов принтеров. Например часть пользователей имеет право печатать на всех принтерах, а часть - только на принтерах какого-то определенного класса. В большинстве случаев,однако, никто такой сложной системой не пользуется.

Быстро пробежимся настройкам:

  • 1.Если вы находитесь на клиенте и на сервере настроен CUPS принтер, то настройки лучше не трогать.

    2.Если сидите на клиенте, а сервер не настроен (например, виндовый сервер с расшаренным по smb принтером), то можно написать его локатор.

jobs --- управление заданиями.

Для того, чтобы добавить принтер вручную. Купс поддерживает целую кучу способов, в том числе и подключение по сети. Эта часть придет позже - ArtemSerebriyskiy

Для того, чтобы завершить разговор о конфигураторах через сеть, можно сказать, что их есть ещё некоторое количество. Есть ещё несколько подсистем, к которым есть конфигураторы с веб-интерфейсом: например, есть конфигуратор к службе samba через веб-интерфейс который называется ???. Пользоваться им нельзя по одной простой причине --- по сути это редактор для конфигурационного файла smb.conf. Но в отличие от конфигурационного файла, который самодокументирован -т.е. вы читаете комментарии внутри него и своеобразно им производите изменения, ??? генерирует большой файл настроек без единого комментария. Это пример того самого случая, когда пользоваться конфигуратором можно только тогда, когда представляешь себе конфигурационный файл.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

15

1

1

1

1

ArtemSerebriyskiy, Allena


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080707/03CUPS (last edited 2008-10-09 18:30:31 by MaximByshevskiKonopko)