Primary Domain Controller (PDC)

Primary Domain Controller (PDC) is a server computer in a pre-Windows 2000 NT server Domain. A domain is a concept used in NT server operating systems whereby a user may be granted access to a number of computer resources with the use of a single username and password combination.

Such domains have at least a Primary Domain Controller, and will often have one or more Backup Domain Controllers (BDCs). The PDC has the master copy of the user accounts database which it can access and modify. The BDC computers have a copy of this database, but these copies are read-only. The PDC will replicate its account database to the BDCs on a regular basis. The BDCs exist in order to provide a backup to the PDC, and can also be used to authenticate users logging on to the network. If a PDC should fail, one of the BDCs can then be promoted to take its place. The PDC will usually be the first domain controller that was created unless it was replaced by a promoted BDC.

In later releases of Windows, such as Windows 2000, NT 4 type domains have been superseded by Active Directory. In Active Directory domains, the concept of Primary and Backup Domain Controllers doesn't exist. Instead, the domain controllers in these domains are all considered to be equal in that all controllers have full access to the accounts databases stored on their machines.

However, in these later releases of Windows, an Active Directory FSMO role named PDC emulator master does exist in each domain. This PDC emulator master does not have the same special role in replication as the Primary Domain Controller in pre-Windows 2000 systems, but does have certain additional responsibilities:

* The PDC emulator master acts in place of the Primary Domain Controller if there are Windows NT 4.0 domain controllers (BDCs) remaining within the domain, acting as a source for them to replicate from.
* The PDC emulator master receives preferential replication of password changes within the domain. As password changes take time to replicate across all the domain controllers in an Active Directory domain, the PDC emulator master receives notification of password changes immediately, and if a logon attempt fails at another domain controller, that domain controller will forward the logon request to the PDC emulator master before rejecting it.
* The PDC emulator master also serves as the machine to which all domain controllers in the domain will synchronise their clocks. It, in turn, should be configured to synchronise to an external NTP time source.

PDC has been faithfully recreated on the Samba emulation of Microsoft's SMB client/server system.

this is configuration in file /etc/samba/smb.conf

[global]
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf if the
# samba-doc package is installed.
# Date: 2005-09-13
[global]
workgroup = NAUFAL-NT
netbios name = NAUFAL-PDC
map to guest
logon path = \\%L\profiles\%U
logon drive = P:
add machine script = /usr/sbin/useradd -c Machine -d /dev/null -s /bin/false %m$
domain logons = Yes
domain master = Yes
local master = Yes
os level = 75
preferred master = Yes
security = user
encrypt password = Yes
[homes]
comment = Home Directories
valid users = %S
browseable = No
read only = No
inherit acls = Yes
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
write list = root
[profiles]
comment = Network Profiles Service
path = /var/lib/samba/profiles
read only = No
create mask = 0600
directory mask = 0700
inherit acls = Yes
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No

Theb you make password for user root samba :
# smbpasswd -a root
Make directory for share profile anda netlogon

# mkdir -p /var/lib/samba/netlogon
# mkdir -p /var/lib/samba/profiles
# chmod 1777 /var/lib/samba/profiles
# /etc/init.d/smb restart
#testparam

This some picture if you have trouble connection from windows to pdc:










then you restart your computer, login with username and password samba.




now you must modifikasi your registry, type regedit in run program


then you choose HKEY LOCAL MACHINE |Current controlset | Service | Netlogon |Parameters

change 1 with 0

bootloader in linux

Boot loader in linux

The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:

* For x86 or x86-64: when the partition boot sector code is executed in real mode and loads the first stage boot loader (typically a part of LILO or GRUB).

From that point, the boot process continues as follows:

The first stage boot loader loads the remainder of the boot loader, which typically gives a prompt asking which operating system (or type of session) the user wishes to initialize. Under LILO, this is done via the map installer which reads the configuration file /etc/lilo.conf to identify the available systems. It includes data such as boot partition and kernel location for each, as well as customized options if any. Upon selection, the appropriate kernel is loaded into RAM memory as an image file ("initrd"), and along with the appropriate parameters, control is passed to it.

LILO and GRUB differ in some ways:

* LILO does not understand file systems, so it uses raw disk offsets and the BIOS for data load. It loads the menu code, and then depending on the response loads either the 512 byte disk sectors for an MBR system such as Microsoft Windows, or the kernel image for Linux.
* GRUB by contrast does have understanding of the common ext2 and ext3 file systems. Because GRUB stores its data in a configuration file rather than the MBR and contains a command line interface, it is often easier to rectify or modify GRUB if misconfigured or corrupt.

GRUB

Source: Red Hat GRUB description.

1. The first stage loader is read by the BIOS from the MBR (master boot record).
2. The first stage loads the rest of the boot loader (second stage). If the second stage is on a large drive, sometimes an intermediate 1.5 stage is loaded, which contains extra code to allow cylinders above 1024, or LBA type drives, to be read. The 1.5 boot loader is stored (if needed) in the MBR or the boot partition.
3. The second stage boot loader executes, and displays the GRUB startup menu. It also allows choice of operating environment, and examination of system parameters.
4. When an operating system is chosen, it is loaded and control is passed.

GRUB supports both direct and chain-loading boot methods, LBA, ext2, and "a true command-based, pre-OS environment on x86 machines". It contains three interfaces: a selection menu, a configuration editor, and a command line console.

LILO

LILO, the older of the two boot loaders, is almost identical to GRUB in process, except that it does not contain a command line interface. Thus all changes must be made to its configuration and written to the MBR, and then the system restarted. An error in configuration can therefore leave a disk unable to be booted without use of a separate boot device (floppy disk etc) containing a program capable of fixing this. Additionally it does not understand file systems, instead locations of image files are stored within the MBR directly and the BIOS is used to access them directly.

Loadlin


Yet another way to boot Linux is from DOS or Windows 9x, where the Linux kernel completely replaces the running copy of this operating system. This can be useful in the case of hardware which needs to be switched on via software and for which such configuration programs are only available for DOS, whereas not for Linux, those being proprietary to the manufacturer and kept an industry secret. This tedious booting method is less necessary nowadays, as Linux has drivers for a multitude of hardware devices, but it used to be helpful in the past.
Another case is when the Linux is located on a storage device which is not available to the BIOS for booting: DOS or Windows can load the appropriate drivers to make up for the BIOS limitation, and boot Linux from there.

simple manual linux

In Linux, the flow of control during a boot is from BIOS, to boot loader, to kernel. The kernel then starts the scheduler (to allow multi-tasking) and runs Init (which sets up the user environment and allows user interaction and login), at which point the kernel goes idle unless called externally.

In detail:

1. The BIOS performs hardware-platform specific startup tasks
2. Once the hardware is recognized and started correctly, the BIOS loads and executes the partition boot code from the designated boot device, which contains phase 1 of a Linux boot loader. Phase 1 loads phase 2 (the bulk of the boot loader code). Some loaders may use an intermediate stage to achieve this (known as phase 1.5) since modern large disks may not be fully readable without further code.
3. The boot loader often presents the user with a menu of possible boot options. It then loads the kernel, which decompresses into memory, and sets up system functions such as essential hardware and memory paging, before calling start_kernel().
4. start_kernel() then performs the majority of system setup (interrupts, the rest of memory management, device initialization, drivers, etc) before spawning separately, the idle process and scheduler, and the Init process (which is executed in user space).
5. The scheduler effectively takes control of the system management, as the kernel goes dormant .
6. The Init process executes scripts as needed that set up all non-kernel services and structures in order to allow a user environment to be created, and then presents the user with a login screen.

On shutdown, Init is called to close down all user space functionality in a controlled manner, again via scripted directions, following which Init terminates and the Kernel executes its own shutdown.