Advertisment

CD-Writing

author-image
PCQ Bureau
New Update

-Mrinal Kalakrishnan

Advertisment

Have

you ever booted into Windows from Linux just to write a CD because you didn’t

know how to do that in Linux? You no longer need to do that. This article

will walk you through CD writing under Linux.

If you own a SCSI CD-Writer,

you don’t need to recompile the kernel, and you can skip this section. If

you have an IDE/ATAPI CD-writer (which is most probable), you’ll have to

make it appear like a SCSI device to the CD-writing applications. The Linux

kernel has a "SCSI host adapter emulation" module, which does

this. But if you don’t want to mess around with kernel configuration, you’re

in luck. PC Quest has provided a kernel RPM in this month’s CD,

which has the IDE-SCSI module (which is used for SCSI emulation) in it, so

all you have to do is install the RPM.

Before you begin, please note

that you have to be root before you can perform any of these tasks. It’s

still a good idea to work as a user though, and then use the command "su"

to become root.

Advertisment

Mount the CD (mount /mnt/cdrom)

and then install the RPM with the command:

# rpm -ivh –force /pcq/goodies/kernel/kernel-2.2.14-12-cdwriting.i686.rpm

Now, you have to run LILO to

update the boot record. You can do that by typing "lilo —v".

Note carefully if there were any errors, then just reboot, and you’ll be

running off the new kernel with the IDE-SCSI module. The module is not in

memory by default. To load the module, type "modprobe ide-scsi".

If you have two CD-ROM drives, the first one will become /dev/scd0, and the

second one /dev/scd1. To get back the normal IDE behavior (/dev/hd?), remove

the ide-scsi module with the command "rmmod ide-scsi", and

load the IDE-CD module with "modprobe ide-cd". By default,

if you mount a CD with "mount/mnt/cdrom", it will autoload

the IDE-CD module. So, in order to use the SCSI emulation, you’ll have to

remove the IDE-CD module first and then load the IDE-SCSI module with "rmmod

ide-cd; modprobe ide-scsi"
.

Advertisment

If you want the normal IDE

behavior for your CD-ROM drive and SCSI emulation only for your CD-Writer,

then add the following line in /etc/conf.modules:

options

ide-cd ignore=hdd

This makes the IDE-CD module

ignore your CD-writer (assuming that it is /dev/hdd). Load the IDE-CD module

first, followed by the IDE-SCSI module. You can also load the modules at

boot time by adding the following two commands in /etc/rc.d/rc.sysinit:

Advertisment

action

"Loading ide-cd module" modprobe ide-cd

action

"Loading ide-scsi module" modprobe ide-scsi

The program you’ll use to

write CDs is called cdrecord, a command-line program. To test if the kernel

module is working fine, and if cdrecord can actually find your CD-Writer,

type "cdrecord-scanbus". You should get an output that

contains the name of your CD-writer, something like this:

Advertisment

Cdrecord

release 1.8a29 Copyright (C) 1995-1999 Jörg Schilling

Using

libscg version "schily-0.1"

scsibus0:

Advertisment

0,0,0 0)

‘PHILIPS ‘ ‘CDD3610 CD-R/RW ‘ ‘3.01’ Removable CD-ROM

0,1,0 1) *

0,2,0 2) *

Advertisment

0,3,0 3) *

0,4,0 4) *

0,5,0 5) *

0,6,0 6) *

0,7,0 7) *

Make a note of the three

numbers next to the name of the CD-Writer (in this case - 0,0,0). These are

the SCSI host, id and lun. You have to give these as parameters to cdrecord

while writing the CD.

Interacting with NT

You might ask

yourself why adding Win NT or 2000 machines should be any different from

adding Win 9x machines. However, there are significant differences in the

SMB implementations between versions of Microsoft’s own operating systems.

Even the password algorithms used by the two operating systems are

different. Win 9x machines don’t actually participate in a Win NT domain

the way NT does. The domain controller in this case is used purely for

authentication.

If you want to use Win 2000

machines in a Samba domain, you’ll need to upgrade to Samba 2.0.7 (Zoot

ships with 2.0.6, so you’ll have to download the updated RPMs). There are

a few subtle changes in 2000, most of which have been addressed in this

release. There are a few outstanding bugs though, but no show-stoppers. Note

that Win 2000 is currently only supported in the backwards compatibility

(with NT PDC) mode, and not in its native domain controller mode.

Adding a Samba server to a

Win NT domain

To get a

Samba server to join a Win NT domain, you must first create a machine

account for the server in the PDC’s SAM (Security Accounting Manager)

database. You can do this using the "Server Manager for Domains"

utility on the PDC. The machine account is created using the netbios name of

the Samba server, which is usually, but not necessarily, its host name.

Once you’ve created the

machine account, you need to configure the smb.conf file. Apart from the

standard configuration, you need to make the following changes:

workgroup = NTDOM (Assume

that the domain name is NTDOM)

security = domain

password server = NTDOMPDC

NTDOMBDC1 NTDOMBDC2

where NTDOMPDC is the name of

the domain controller, NTDOMBDC<1,2> are the names of the backup domain

controllers, and SAMBA is the netbios name of the samba server.

Now, before restarting the

smbd daemons, give the command

# smbpasswd -j NTDOM -r

NTDOMPDC

This command will create a

file called SAMBA.NTDOM.mac in your /etc/ directory, containing the machine

account password for the Samba server.

Assuming all goes well, you

should get a message saying

smbpasswd :

Joined domain NTDOM

Adding an NT server to a

To add

a Win NT machine to a Samba domain, you need to create a user entry

for it in the password file. This is the Samba equivalent of creating a

machine account in the SAM database. The username should be the name of the

machine, appended with a "$". Set no password, and set the home

directory to /dev/null, and shell to /bin/false. (You might have to escape

the "$" on the command line with a "\", if required)

# useradd ntserver$ -s /bin/false -d /dev/null

The next step

is to go to the NT machine, and set the domain name to SAMBADOM (where

SAMBADOM is the domain name). Take care not to check the "create a

machine account" check box. This feature is not yet supported. You

should get a message saying "Welcome

to the SAMBADOM domain".

Understanding server

configuration options

If you look

at the man page for the smb.conf file (man 5 smb.conf), you’ll find a

number of configuration options that you can use to tweak the performance

and customize your Samba configuration further. Due to the lack of space

here, I’ll take a look at only a few configuration options.

One of the more misunderstood

configuration parameters is the "security=" option. We’ll take a

brief look at what the various options mean.

security=share

This is the conventional, and

most brain-dead option available. Shares exported will be available to any

machine in the workgroup without further authentication. This is commonly

used for machines sharing public shares, CD-ROMs, etc. Use this only when

you have no security concerns whatsoever.

security=server

Server level security is used

when you want the Samba server to authenticate users against another Samba

or Windows NT machine acting as a domain controller. This is a good idea

when you have a number of machines on your network, with users needing to

logon to the domain to be able to access the shares. In this case, you’ll

have to configure the "password server" parameter to specify the

names of the authentication servers (normally the PDC and BDC).

security=user

In this scheme, the Samba

server actually acts as a workgroup controller, authenticating Windows NT

and Win 9x clients. A separate user list has to be maintained, and users are

added using the "smbpasswd" command. In this case, the Samba

server maintains its equivalent of an NT SAM database.

security=domain

Domain level security is used

in the case described above, when adding a Samba server to a Win NT domain.

Here too, you’ll need to specify the "password server"

parameter. So how’s this different to the "security=server"

configuration? For one, when using server level security, the Samba server

will open and maintain a network connection to the domain controller during

the entire session. This can be a significant drain on network resources. In

domain level security, a connection is established for exchanging

authentication information only.

There are some new parameters

in Samba 2.0.7 as well. Most of these deal with the new utmp and wtmp

support (experimental, I might add) included in this version. This will

enable users logged in via Samba to be seen using the "who"

command, and all login information to be recorded in the system logs, not

just the samba logs. You’ll need to specifically compile support for this

using the



"–with-utmp" flag to "configure".

Samba development

Samba

development is progressing at an extremely hectic pace. There are currently

four trees under active development (For those new to the open source style

of development, a "tree" consists of all the latest source code of

the software, to which developers have access. Developers "check

in" portions of code they are working on, and then "check

out" the new code for others to test and debug when they have

finished).

There is the SAMBA_STABLE

branch, which has the regularly released "stable code", for you

and me to use. New features are not introduced into this tree until they’ve

been thoroughly tested in unstable versions. The stable Samba tree at this

time doesn’t have the ability to be a domain controller for Win NT

machines.

The second branch is the

SAMBA_TNG branch, which is where the main thrust of development is going on

at the moment. TNG stands for "The Next Generation", and includes

all the "cool code", such as domain controller for NT and Win 2000

machines, support for NT- specific administrative tools such as "User

Manager for Domains", and trust relationships, etc.

The Third branch is the

SAMBA_HEAD branch, which is the successor to the current 2.0.x series. It

contains improved file and print sharing services and NT file permissions

support. However, it contains no NT PDC support.

The last and final branch is

the HEAD_WITH_TNG branch, which is exactly what you might imagine from its

name.

The most interesting of these

branches is the SAMBA_TNG branch, which focuses on Win NT PDC controller

code. It currently suffers from poor file serving ability, but code mergers

with the SAMBA_HEAD branch will take care of this problem in the near

future.

So if you’re a hacker, or

kid with a network and time to spare, download the TNG or HEAD branch and

play with the code. Finding bugs or contributing documentation is the

easiest way to help the development effort, if you’re not a developer

yourself.

Babu Kalakrishnan, a Director at Sankya System & Objects, Bangalore www://www.sankya.com

Advertisment