server, it was easy to create a script that could pick up that file, extract out the useful lines, and generate the web page from it.

I have since used this technique in many situations in which I didn't want to have to write a user interface and the user already had MS Excel.

Letting Others Do Privileged Operations

Often we are asked to create a way for normal users to do things typically permitted only by an administrative account such as root. This can be quite dangerous and should be done with great care.

In Unix/Linux, there is a program called sudo that lets system administrators give a person the ability to run a command as another user. It is very restrictive, requiring the system administrator to configure it to specify exactly which user(s) can run which command(s) as which other user.

For example, you can configure it to permit a particular person to run a command as root. You can rely on sudo to make sure that only the people you specify have the ability to run this command as root, but it is important that the program check the parameters to make sure that privileged users are able to overstep their bounds.

Warning

Any kind of system that lets 'normal' people do 'privileged' operations is a risky system to build. Computer security history is fraught with well-meaning programmers accidentally creating security holes that let people run any command as root or administrator.

If you aren't sure what you are doing, research security books and FAQs for advice.

For example, if it requires root to run the Unix mount command to access a CD-ROM. It is a bad idea to configure sudo so that the person can run the mount command as root with any parameters. He could crash the system or break security. It is much better if you configure sudo to let the person run a new command (say, mountcd) as root. This command will make sure that he has specified the particular CD-ROM drives that the user is permitted to mount (with a logical default), and mounts that drive. You also want to give him an (unmountcd) command.

I like to build three layers when I automate something for other people:

Layer 1. A program that does the basic task.

Layer 2. A program that the user will run, with sudo, that collects her input, validates it, makes sure she isn't trying to do anything fishy, and then calls the first program.

Layer 3. A more user-friendly way to access these previous layers, such as a web interface or menu program.

For example, at one company, we had a process for pushing a new version of the company web site to the world. It involved three different web servers (actually they were virtual servers on two different machines, but those details aren't important).

www-draft.example.com

The next release of our web site was developed here.www-qa.example.com

The draft site would be copied here for QA to check over. Once the copy was made, the files were immediately made read-only. If QA approved this site, we needed to be able to verify that these exact bits were copied to the live site.www.example.com

This was the live site that external people would see.

The web designers would ask the system administrators to copy their draft to www-qa.example.com. When the QA group approved the site, they would tell the system administrators to make the site go live.

Each of these two functions was automated:

readyforqa

Copied the draft site to the QA site.golive

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату