Assuming that you have both NGINX and Apache installed...

1. Select different IP addresses for each one.

Let's setup the hosts file for quick access to start pages.

sudo nano /etc/hosts

append lines (use any local IP you like)

127.0.0.1   nginx
127.0.0.2   apache

2. Setup listen IP and port for NGINX

NGINX must listen on one IP address only.

sudo nano /etc/nginx/sites-enabled/default

And replace the lines

--- (remove lines) +++ (add lines)

--- listen 80 default_server;
--- listen [::]:80 default_server;
+++ listen nginx:80;

If you want to use SSL, make the same things for 443 port.

IMPORTANT!

Make sure all enabled NGINX websites listen on nginx:80

Restart NGINX

sudo service nginx restart

Make a check using command sudo netstat -tulpn | grep :80

tcp        0      0 127.0.0.1:80            0.0.0.0:*               LISTEN      26540/nginx: master

Done! Now you can access default NGINX host by url http://nginx

3. Setup listen IP and port for Apache

Apache must listen on one IP address only as well.

Ports:

sudo nano /etc/apache2/ports.conf

And replace the lines

--- (remove lines) +++ (add lines)

--- Listen 80
--- Listen 443
+++ Listen apache:80
+++ Listen apache:443

Default virtual host:

sudo nano /etc/apache/sites-enabled/000-default

And replace the lines

--- (remove lines) +++ (add lines)

--- <VirtualHost *:80>
+++ <VirtualHost apache:80>

If you want to use SSL, make the same things for 443 port.

IMPORTANT!

Make sure all enabled Apache websites listen on apache:80

Restart Apache

sudo service apache2 restart

Make a check using command sudo netstat -tulpn | grep :80

tcp        0      0 127.0.0.2:80            0.0.0.0:*               LISTEN      26829/apache2

Done! Now you can access default Apache host by url http://apache

You clearly cannot clone a larger partition to a smaller partition (using dd and the like) since there is simply not enough space.

However, if the files that are on the larger partition would also fit on the smaller partition, you could use rsync to copy those files. The exact options to use depend on your particular use case, but to simply copy all the files the following should do:

rsync -av /mount/point/of/large/partition/ /mount/point/of/small/partition

Edit: Once again: You cannot clone a larger partition onto a smaller partition. (But do read on, your problem can be solved yet.)

The reason is simple: your source partition is bigger than your target partition. What do you expect? Should some blocks just be dropped? Which ones? And how should dd know? Of course, you could use dd's bs= and count= options to only copy the first so-and-so-many blocks of your source partition such that it fits onto your target partition, but you will end up with a broken partition. That is certainly not what you want.

So, since you cannot clone a larger partition onto a smaller partition, the only thing you could do is to first reduce the size of your source partition to a size smaller or equal to that of your target partition with something like gparted which is aware of the filesystem specifics, such that you do not lose data. And only then could you use dd to clone the partition. Ideally, the new size of your source partition should be equal to the size of your target partition (and not just smaller or equal), or else you will end up with some unallocated space on your target partition after the cloning.

Please also note that you should not simply copy an MBR of a larger drive onto the MBR of a smaller drive (or vice versa, for that matter). The MBR, which has a size of 512 bytes and is the first section of your hard drive, contains information on the layout of the harddrive:

• 446 bytes - Bootstrap.
• 64 bytes - Partition table.
• 2 bytes - Signature.

(Note that 446+64+2=512.)

If you insist on cloning the MBR, then only clone the first 446 bytes like so:

dd if=/dev/source of=/tmp/mbr.bak bs=512 count=1
dd if=/tmp/mbr.bak of=/dev/target bs=446 count=1

...replacing /dev/source and /dev/target with the device names of the source and target harddrives, e.g., /dev/sda and /dev/sdb, respectively. (More information is available here.)

However, the proper way to do it would be to do a clean Grub reinstall (or whatever you have on your MBR) on the new harddrive.

Summing up, if you want to clone a larger drive onto a smaller drive, proceed as follows:

1. Lay out a partition table on the target drive with as many partitions as on the source drive. There should be a one-to-one correspondence between the partitions on your source drive and the partitions on your target drive, except that (some of) the partitions on the target drive can be smaller than their corresponding partitions on the source drive. Use a tool such as fdisk or cfdisk for that.

2. For each partition on the target drive which is smaller than its corresponding partition on the source drive, reduce the size of this corresponding partition on the source drive to match the size of the partition on the target drive. Use a tool such as gparted for that.

3. For each partition on the source drive, issue the command

   dd if=/dev/sdaX of=/dev/sdbY
   

   ... to clone the partition /dev/sdaX from the source drive to the corresponding partition /dev/sdbY on the target drive (replace the device names appropriately, of course.)

4. If you insist on also cloning the MBR, use the two dd commands written further above in this post (those with the /tmp/mbr.bak stuff). However, keep in mind that a clean Grub re-install would be better.

Online Method (using qemu, libvirt, and virtio-block)

For better or worse, the commands below will run even if the target virtual disk is mounted. This can be useful in environments where the disk cannot be unmounted (such as a root partition), the VM must stay on, and the system owner is willing to assume the risk of data corruption. To remove that risk, you would need to log into the VM and unmount the target disk first, something that isn't always possible.

Perform the following from the KVM hypervisor.

1. Increase the size of the disk image file itself (specify the amount to increase):

   qemu-img resize <my_vm>.img +10G
   

2. Get the name of the virtio device, via the libvirt shell (drive-virtio-disk0 in this example):

   virsh qemu-monitor-command <my_vm> info block --hmp
     drive-virtio-disk0: removable=0 io-status=ok file=/var/lib/libvirt/images/<my_vm>.img ro=0 drv=raw encrypted=0
     drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
   

3. Signal the virtio driver to detect the new size (specify the total new capacity):

   virsh qemu-monitor-command <my_vm> block_resize drive-virtio-disk0 20G --hmp
   

Then log into the VM. Running dmesg should report that the virtio disk detected a capacity change. At this point, go ahead and resize your partitions and LVM structure as needed.

You can use the Linux Bash core utility split:

split -b 1M -d  file.txt file

Note that M or MB both are OK but size is different. MB is 1000 * 1000, M is 1024^2

If you want to separate by lines you can use -l parameter.

Update:

a=(`wc -l yourfile`) ; lines=`echo $(($a/12)) | bc -l` ; split -l $lines -d  file.txt file

Another solution as suggested by Kirill, you can do something like the following

split -n l/12 file.txt

Note that is l not one, split -n has a few options, like N, k/N, l/k/N, r/N, r/k/N.

readarray -t lines < file.txt
count=${#lines[@]}

for i in "${!lines[@]}"; do
    index=$(( (i * 12 - 1) / count + 1 ))
    echo "${lines[i]}" >> "file${index}.txt"
done

awk '{
    a[NR] = $0
}
END {
    for (i = 1; i in a; ++i) {
        x = (i * 12 - 1) / NR + 1
        sub(/\..*$/, "", x)
        print a[i] > "file" x ".txt"
    }
}' file.txt

even more concise :
      

zip -rX ../my.epub mimetype META-INF/ OEBPS/

Without -X you could get the following when validating it with EpubCheck:

ERROR: my.epub: Mimetype entry must not have an extra field in its ZIP header

If mimetype is not the first in the epub file EpubCheck prints the following:

ERROR: my.epub: Mimetype entry missing or not the first in archive

Linux uses the name of the current folder as the epub filename:
zip -rX "../$(basename "$(realpath .)").epub" mimetype $(ls|xargs echo|sed 's/mimetype//g')

I found this version also worked better for epubs I found that don't use the OEBPS folder. I don't know if not having that folder is valid per standards, but I found examples of it being missing in the wild.