I came across uuidgen from watching a video to study for the redhat 8 exam but I had a question about it's usefulness and did not find any other thread nor did the manpage mention it. So I understand that each device has an UUID and the UUID can be used for multiple purposes - the purpose in the video was creating new mountpoints and the UUID was used to associate a new partition (/dev/sdb3) with a new mountpoint. Here they pointed out that you can generate a new UUID for that device using uuidgen.
My question is why/when would you use uuidgen in a production environment with live servers to relabel a partition? What would be the point of relableing the UUID for a currently existing mountpoint? Is there a sort of attack that target UUID of a system? Or is the sole purpose for uuidgen just used to create random UUIDs for others things like web links?
Thanks
Say you have a system with several disks, one partition each, and you need to play "Musical Data" with some of them.
If you start by copying, at block level via e.g. dd, the entire GPT-partitioned disk, then you will have, as a result, a duplicate UUID. This is fine if one of the duplicates is going to be blown away before the next time the OS needs to mount one of them. If, for whatever reason, this can not be ensured, then whichever copy you don't want the OS to pick up anymore, needs a new UUID. Enter uuidgen.
I'm assuming you're talking about GPT partition UUIDs, which are stored all together in each GPT that contains the identified partitions; if, instead, you're talking about filesystem UUIDs, which are stored inside the metadata for that filesystem and thus are copied whenever dd'ing that filesystem, then the above scenario still holds and more scenarios become plausible.
Related
I am looking for a program that would allow me to mirror one partition to another disk (something like RAID1) for Linux. It doesn't have to be a windowed application, it can be a console application, I just want what is in one place to be mirrored to another.
It would be nice if it were possible to mirror a specific folder that I would care for instead of copying everything from the given partition.
I was looking on the internet, but it's hard to find something that would give such opportunities, hence the idea to ask such a question.
I do not want to make fake RAID on Linux or hardware RAID because I read that if the motherboard fails then it is best to have the same second one to recover data.
I will be grateful for every suggestion :)
You can check my script "CopyDirFile" written in bash, which is located on github.
You can perform a replication (mirroring) task of any source folder to another destination folder (deleting a file in the source folder means deleting it in the destination folder).
The script also allows you to create copy tasks (deleted files in the source folder will not be deleted in the target folder).
The tasks are executed in background at a specified time, not all the time, frequency is set by the user when creating the task.
You can also set the task to start automatically when the user logs on.
All the necessary information can be found in the README file in repository.
If I understood you correctly, I think it meets your requirements.
Linux has standard support for software RAID: mdraid.
It allows you to bundle two disk devices into a RAID 1 device (among other things); you then create a filesystem on top of that device.
LVM offers another way to do software RAID; it doesn't seem to be very popular, but it's certainly supported.
(If your system supports hardware RAID, on the motherboard or with a separate RAID controller, Linux can use that, too, but that doesn't seem to be what you're asking here.)
When writing software which needs to cache data on disk, is there a way in libc, or a way which is specific to a certain file system (such as ext4), to create a file and flag it as suitable to be deleted automatically (by the kernel) if the partition becomes almost full?
There’s something similar for memory pages: madvise(…, MADV_FREE).
Some systems achieve this by writing a daemon which monitors the partition fullness, and which manually deletes certain pre-determined paths once it exceeds a certain fill level. I’d like to avoid this if possible, as it’s not very scalable: each application would have to notify the daemon of new cache paths as they are created, which may be frequently. If this were in-kernel, a single flag could be held on each inode indicating whether it’s a cache file.
Having a standardised daemon for this would be acceptable as well. At the moment it seems like different major systems integrators all invent their own.
You can use crontab job, and look for specific file extension and delete it. You can even filter based on time and leave the files created in last n minutes.
If you are ok with this, let me know, I will add more details here.
All the web content and its acronym explains it as Uniquely identifier.
But when i try to create another device, lets say swap in my case and assign the UUID, i am able to assign many UUIDs to single slice of disk.
I can create multiple swap device with different UUIDs, using command mkswap with -U option to it.
Then, how it is unique..?
It's Unique in the sense that the same UUID should not be generated twice. This is not exactly guaranteed, because part (sometimes all) of the generation process uses random numbers, but statistically it is unlikely that a new UUID will be in use anywhere else in the world.
The scenario is as follows: an encryption key should be stored temporarily, so that multiple instances of an application can access it (sequentially). After use, the key should of course be removed from the system. However, this imposes a problem. I accept that the system is vulnerable as long as the key is stored, but I want the system to be secure before and after the key is stored.
Simply writing the key to a file and overwriting it afterwards will not work in all cases: some filesystem write changes to different parts of the disk, instead of to the same location. In that case, the key can still be retrieved afterwards. I cannot rely on the user having full-disk encryption.
Then the most logical option seems to use an other process that keeps the key in memory, but the operating system might write the memory to the disk at certain points, resulting in the same problem as described above.
Encrypting the key is possible, but this is not more secure. The whole point of storing the key temporarily, is that the user need not type it in for every run of the program. This means that the key used to encrypt the key must also be stored somewhere, or it must be based on known data. If the key is stored, then of course we now have the problem of securely storing this key. If it is based on known data, that means the key can be generated again when necessary, so encryption has little use.
I know some operating systems offer APIs to protect data, but this usually relies on generating an encryption key based on the user account information. Even if this is session-specific, the data will not be secure until the session ends (which can be long after the key should be erased).
Is there any solution to this problem at all (that does not rely on special hardware, does not require full-disk encryption, etc.)? If there is not, what is the best I can do in this case?
Edit for clarification:
The key need not be secure when it is stored in memory; at this point, the user should guarantee that no physical access is possible, and that the system is free of viruses. After the key has been used, it should be erased from the system, such that afterwards anyone with physical access, or any program, can inspect all memory and disks, and not find a single (usable) trace of the key any more.
You could use ramdisks (not tmpfs). See http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt:
"Another similar thing is the RAM disk (/dev/ram*), which simulates a fixed size hard disk in physical RAM, where you have to create an ordinary filesystem on top. Ramdisks cannot swap and you do not have the possibility to resize them."
So basically, you need to create a filesystem on /dev/ram* and then mount it somewhere. However, this mount point can then be accessed by all processes, not only specific ones.
I have made a Linux CUI app that communicates between processes via Message-quene.
There is no problem with it as long as it is a single instance. However when there are multiple instances of the same app, the messages in the quene get sent to the wrong instance.
I understand this can be avoided by giving the msgget function a unique key.
Using ftok() to create a key, but since the variables are the same they result in
identical keys.
Can someone guide me how to have a unique key for each instance?
The only idea I have now is to randamize the variable given to ftok, and
I know that cant be right.
Be careful with ftok!
This will only be unique for a given file system and only if then if
the file system is not heavily used.
fttok is driven by the file entry number in the file system.
This used to be a pretty good way of getting unique values but time
and Moores law caught up with it a few years ago. It works on the
lower 8 bits of the file number but the actual file number is now 32 bits
and numbering starts again for each file system.
Process id is a pretty good choice, they do get re-cycled but not as
long as the process is still alive.
You could try using the process id. My google foo got this
Looking globally unique ids usually called Guid or Uuid. There must be a library you can use to generate them. They are unique strings made from your nic address, the current time, and a random number.
How about the clock? WikiPedia say's it's better than RDTSC (and SMP safe).
"Under Linux, similar functionality is provided by reading the value of CLOCK_MONOTONIC clock using POSIX clock_gettime function."