Ubuntu Multiple interfaces on the same subnet

7 down vote accepted

OK, it is working, and for referencing here is how I did it, hopefully someone will find it useful. I found the solution on the following sites: 1- Multiple interfaces on the same subnet 2- Two network interfaces and two IP addresses on the same subnet in Linux And the website that i referenced in the question as well. suppose I have two IP addresses: 7.7.7.4 & 7.7.7.5 on network 7.7.7.0 and they have a gateway 7.7.7.1 I enabled ARP filtering: # sysctl -w net.ipv4.conf.all.arp_filter=1 # echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf And the I configured /etc/network/interfaces as following: # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 7.7.7.4 network 7.7.7.0 netmask 255.255.255.0 broadcast 7.7.7.255 up ip route add 7.7.7.0/24 dev eth0 src 7.7.7.4 table eth0table up ip route add default via 7.7.7.1 dev eth0 table eth0table up ip rule add from 7.7.7.4 table eth0table up ip route add 7.7.7.0/24 dev eth0 src 7.7.7.4 auto eth1 iface eth1 inet static address 7.7.7.5 network 7.7.7.0 netmask 255.255.255.0 broadcast 7.7.7.255 up ip route add 7.7.7.0/24 dev eth1 src 7.7.7.5 table eth1table up ip route add default via 7.7.7.1 dev eth1 table eth1table up ip rule add from 7.7.7.5 table eth1table up ip route add default via 7.7.7.1 dev eth1 up ip route add 7.7.7.0/24 dev eth1 src 7.7.7.5 And I added the following two lines to /etc/iproute2/rt_tables 10 eth0table 20 eth1table

Linux changing Nice cpu priority to process

Finding the current niceness value

Before we start changing niceness values I want to go over identifying what the current nice values are.

Determining the default niceness value of new processes

Different OS distributions can have different default values for new processes. The simplest method to determine the default value is to simply run the nice command with no arguments. By default nice will simply return the current niceness value.
Example:

$ nice
0

In this example we see the niceness value of 0 is the default.

Determining the niceness value of a current process

The niceness value of current processes are also pretty simple to find as they are visible in the ps command's long format.
In the below example we are going to find the current niceness value of the sshd (PID 941) process.

$ ps -lp 941
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 0 941 1 0 70 -10 - 1713 poll_s ? 00:00:00 sshd

Just in case the formatting of this post doesn't make it easy to see, the column NI is the niceness value of the sshd process. In this case it is currently set to -10.

Making a process nicer, decreasing the CPU Priority

Niceness values range from -20 (the highest priority, lowest niceness) and 19 (the lowest priority, highest niceness). In order to prevent a process from stealing CPU time from high priority processes, we will increase the processes niceness value.

Changing the nice value of a new process

Changing the niceness value of a new process is fairly simple. The nice command itself will run the supplied command with the desired niceness value.
Example:

$ nice -n 19 ./test.sh 
My niceness value is 19

This method is helpful for CPU intensive processes that are not as time sensitive as other processes running on the system. By increasing the niceness value, we allow other processes on the system to be scheduled more frequently. I do want to highlight again that while this value is adjustable it can be ignored by the kernel's scheduler in Linux implementations.

Changing the nice value of a running process

To change the niceness value of a running process we will utilize the renice command. The usage is similar to nice however rather than supplying a command to run we will be supplying a process id.
In this example we will be adjusting the priority of the sshd process I showed above.

# renice -n 10 -p 941
941 (process ID) old priority -10, new priority 10

It is important to note that only the root user can modify the niceness value of other users processes. However a regular unprivileged user can adjust the niceness value to a "nicer" value on processes owned by that user.

Making a process less nice, increasing CPU priority

Now that we have adjusted processes to becoming nicer to the system, let us make a process that is less nice. By changing the priority of a process to a negative number, we are suggesting to the scheduler that it should provide higher priority to the specified process.

Changing the nice value of a new process

The method of changing a process to be less nice is the same as making a process nicer.
Example:

# nice -n -20 ./test.sh 
My niceness value is -20

Changing the nice value of a running process

To change the niceness of a running process to a negative value we will use the renice command again.

# renice -n -10 -p 941
941 (process ID) old priority 10, new priority -10

It is important to note that changing a processes niceness value to a negative value requires root privileges. As the effects of giving a process a higher priority could have detrimental effects on a system.
It is advisable to reserve setting niceness values to -20 only when absolutely necessary; as this would suggest to the kernel scheduler that the specified process has the same CPU priority as kernel worker threads.

---

If you mess up your ubuntu box with Ati drivers

Have you tried removing the aticonfig?

sudo aticonfig --uninstall

If it persists..

sudo apt-get remove --purge fglrx fglrx_* fglrx-amdcccle* fglrx-dev*
sudo rm /etc/X11/xorg.conf
sudo apt-get install --reinstall xserver-xorg-core xserver-xorg-video-intel libgl1-mesa-glx libgl1-mesa-dri libgl1-mesa-glx:i386 libgl1-mesa-dri:i386
sudo dpkg-reconfigure xserver-xorg
sudo shutdown -r now

Windows 7 10 disk recovery with commnd prompt

Command prompt > type diskpart.
Type list disk, find the one that is your SD card, by matching the capacity, and remove all other flash disks to keep confusion minimal.
It isn't likely that your hard drive matches your SD card size, I hope. Anyway, it will have a Disk # next to it.
Now type "select disk #" where number is the SD card. Now type "clean". Then go into Disk Management by typing "compmgmt.msc" in the Run window and selecting Disk management on the left pane. You should get a message saying that a disk must be initialized. If not, then look through the list of disks for the SD card, and it should say "Not Initialized".
Right click, initalize, select MBR and follow the rest of the info. This was the method I used on my flash drive to clear out linux mbr bootloaders.

For SD cards try:

Disk Recovery with Linux and testDisk tool.

Make an image before doing ANYTHING, then make a copy of the image, and do your work on that. Then you can always revert back to a pristine image of the card in case something messes up the image.

dd if=/dev/sde1 of=sdcard.img bs=1M

fdisk -l /root/sdcard.img will give you all the info about the img file created 

Always
Then you can setup a loop device with that image and work with that:

# losetup -f gives a list of loop devices available

# losetup /dev/loop0 disk.img
# file -s /dev/loop0
/dev/loop0: Linux rev 1.0 ext3 filesystem data
# mount -o loop /dev/loop0 /mnt
[...]
# umount /mnt
# losetup -d /dev/loop0

then use testdisk on the mounted file system.

(to install testdisk apt-get install testdisk) more here:

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step 

(Your loop device will be /dev/loop0 or similar, find out with losetup -a)

OTHER INFO.
The problem is that the .img files are not images of a partition, but of a whole disk. That means they start with a bootloader and a partition table. You have to find out the offset of the partition and mount it with the offset option of mount.
If you do a

Code:

fdisk -l /path/to/image

it will show you the block-size and the start-block of the partition. You can use that to calculate the offset.
For example, I have an image of a bootable stick with a 4GB FAT32 partition. The output of the fdisk command is

Code:

Disk Stick.img: 3984 MB, 3984588800 bytes
249 heads, 6 sectors/track, 5209 cylinders, total 7782400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0004bfaa

    Device Boot      Start         End      Blocks   Id  System
Stick.img1   *         128     8015999     4007936    b  W95 FAT32

So I have a block-size of 512 bytes and the start-block is 128. The offset is 512 * 128 = 65536.
So the mount command would be

Code:

mount -o loop,offset=65536 Stick.img /mnt/tmp

 then do testdisk on image directly.

testdisk ./image.imge

Migrating a live system from ext3 to ext4 filesystem

This article is meant to serve as a guide for migrating a live system from ext3 to an ext4 filesystem, including migration of files to use extents, a major feature in ext4. It describes the entire migration procedure, including common pitfalls involving a migration of a live system, as opposed to doing a fresh install.

Reasons for conversion

The explanation of advantages and disadvantages of ext4 is beyond the scope of this article. If you are not affected by the limitations of ext3, and not willing to take risks, it may not be worth it. On the other hand, on successful completion of the migration procedure your system may perform faster, experience shortened file system checks, and have increased reliability with no ill effects.

Trying ext4 without conversion

An interesting property worth noting is that you can mount ext3 filesystems as ext4 without doing the conversion first. All you need to do is to modify your /etc/fstab to say "ext4" instead of "ext3" for all your filesystems, and reboot. This way you will be able to go back to ext3 at any time.
This may be a nice test before attempting full conversion, but this will only enable ext4 features that are compatible with ext3. And that means that no major feature of ext4, like extents, will be enabled.

Migrating to ext4

Word of warning

Do a backup before attempting this procedure. It may render your system unbootable, and may destroy your data.
Your filesystems will become incompatible with ext3, so you need to make sure that you have a complete toolkit available with ext4 support before doing a conversion. This includes a bootloader, e2fsprogs, mount, and a recent kernel.

Prerequisites

• e2fsprogs 1.41.6
• mount 2.16
• linux-image 2.6.30
• grub 1.96+20090808

All of these packages are available in Debian unstable or experimental. Lower versions may work, except for e2fsprogs - this is indeed the lowest version.

Converting a non-root filesystem to ext4

As long as you are converting a filesystem that can be unmounted, it is fairly simple procedure. In this example we will be converting a /dev/sdc1 partition mounted as /home directory.
First, unmount the partition.

umount /dev/sdc1

Next, run a filesystem check on it to make sure it is in sane condition. We are still on ext3.

fsck.ext3 -pf /dev/sdc1

Enable new features of ext4 on the filesystem.

tune2fs -O extents,uninit_bg,dir_index /dev/sdc1

Option "extents" enables the filesystem to use extents instead of bitmap mapping for files, "uninit_bg" reduces file system check times by only checking used portions of the disk, and "dir_index" allows storing the contents of large directories in a htree for faster access. Option "dir_index" is also supported by ext3, so you may already be using it, but it makes no harm to specify it here.
Run a filesystem check. It will find errors. It is normal. Let it fix them. You may want to run the check twice to make sure that the filesystem is now clean.

fsck.ext4 -yfD /dev/sdc1

The "-D" parameter will actually enable the "dir_index" option by rebuilding directory index. It can be rebuilt (optimized) at any later time by running the check with the parameter.
Now edit your /etc/fstab file to say "ext4" instead of "ext3" for /home. Other options may differ for your system.

/dev/sdc1 /home ext4 defaults 0 2

Try to mount your new ext4 filesystem.

mount /home

If it succeeds, congratulations. If not, do not panic. You have not lost your data. And you have a backup after all, right? Make sure you have all the latest tools listed in prerequisites. Get them form Debian unstable or experimental if needed. Upgrade and try again.

The /boot partition

If your /boot is a separate partition, all is good and great. Just leave it as ext3. Latest development grub versions do have support for ext4, but it still may and will fail for some given snapshot of grub.
As ext3 can be mounted ext4 without conversion, you can just edit your /etc/fstab to say "ext4" instead of "ext3" for boot partition.

/dev/sdb1 /boot ext4 defaults 0 1

Most features of ext4 will not be used, but that makes little difference for /boot, as it is only used early at boot time. And since this is essentially still an ext3 partition, grub will have no problem booting it.
If, on the other hand, you do not have a separate /boot partition, you should consider creating one. Otherwise you must be really careful, and not enable features not supported by grub, or make sure that you are using a version of grub that supports all of them.

Converting a root filesystem to ext4

Converting a root filesystem is a bit more tricky because you cannot unmount it, as your system is running on it. Nevertheless it is still possible to do it without using an external bootable media. You should do this in a single-user mode.
First step is to modify your /etc/fstab file to say "ext4" instead of "ext3" for root partition. This is important because you will be operating on a read-only filesystem later, and will not be able to make the change, and this would result in your system unable to mount a root filesystem on next boot.
Let us assume that root partition is /dev/sda1, so your /etc/fstab should look something like this.

/dev/sda1 / ext4 defaults 0 1

Now remount the root filesystem read-only.

mount -o remount,ro /

Then run a filesystem check on the root filesystem.

fsck.ext3 -pf /dev/sda1

It will tell you to reboot the system. That may be a good idea, so simply boot into single-user mode and remount it read-only again. It is fine even though we have already modified /etc/fstab, because ext3 can be mounted as ext4 without conversion.
Next, enable all the ext4 features on the root filesystem.

tune2fs -O extents,uninit_bg,dir_index /dev/sda1

And run run a filesystem check on the root filesystem again. It will find and fix errors. This is normal.

fsck.ext4 -yfD /dev/sda1

You can now reboot to your new ext4 system, and enjoy faster filesystem check times, better performance, and all the improvements of ext4. Well, almost; read the next section.

Migrating files to extents

It may seem that the migration from ext3 to ext4 is now complete, and it is almost true. Except that any old files created before the conversion will continue using the bitmap mapping of ext3 instead of extents of ext4.
Files will eventually migrate to the new format as they are updated during normal system operation, because on next write they will be saved using extents. Unfortunately many frequently used files (like application binaries) are often read and rarely written to. The outcome is that the files will remain using the old format for a long time, and you will not be able to experience full potential of ext4.
A utility called e4defrag, which would be able to migrate files, is being developed. But unfortunately it is far complete, and is not suitable for use on real data as of time of writing.
Fortunately it is possible to migrate separate files to extents by using chattr utility, which comes with e2fsprogs package. It allows you to set an attribute on a file which causes the kernel to rewrite the file using extents. It even possible to do this on a mounted and working file system. In fact, that is the only way to do it.
Please not that this feature is still experimental and has not been tested thoroughly. Performing such operation may be dangerous. It may also flood your system log with warnings and errors. You should first test this on small number of insignificant files.
You can check if a file (or a directory) is using extents with lsattr.

lsattr /home/user/foo/bar

If it not using extents, the output will be something like this.

------------------- /home/user/foo/bar

The dashed line here is simply a placeholder for various attributes a file can have. This means that it has no attributes.
Now set the attribute to use extents on the file.

chattr +e /home/user/foo/bar

Now list the attributes again, and you will notice that the output looks like this.

-----------------e- /home/user/foo/bar

Note the "e", which means that it is now using extents.
Check your system log and look for scary things. Not finding any is a good sign. That means you can continue.
Modifying attributes with chattr can be done on multiple files. Although digging trough the entire directory system is not really feasible, so you can use some of the shell magic to accomplish the task.

find /home -xdev -type f -print0 | xargs -0 chattr +e
find /home -xdev -type d -print0 | xargs -0 chattr +e

The first command will run "chattr +e" on all files in /home, and the second will do the same for directories.
It is possible to run this on the root directory and convert everything at once. But running this on one file system at a time with "-xdev" parameter will prevent it from diving into file systems that do not support extents. It may also be useful to run filesystem check on a partition after conversion.
It may make sense to perform this in single-user mode to minimize the chances of something interfering with a task. You may also want to shutdown syslog, as it may generate a lot of warnings.

How to Enable / Disable Multiple RDP Sessions in Windows 2012

How to Enable/Disable Multiple RDP Sessions in Windows 2012By default, Windows 2012 servers allow a single Remote Desktop session. If only one session is available and you take over another person's live session, you may choose to enable multiple RDP sessions. This article describes the process for enabling and disabling multiple sessions.

Enable Multiple RDP Sessions

1. Log into the server using Remote Desktop.
2. Open the start screen (press the Windows key) and type gpedit.msc and open it
3. Go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections.
4. Set Restrict Remote Desktop Services user to a single Remote Desktop Services session to Disabled.
5. Double click Limit number of connections and set the RD Maximum Connections allowed to 999999.
   

Disable Multiple RDP Sessions

1. Log into the server using Remote Desktop.
2. Open the start menu and type 'gpedit.msc' and open it
3. Go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections.
4. Set Restrict Remote Desktop Services user to a single Remote Desktop Services session to Enabled.