What is the best-practiced way to get an unique machine ID in GNU/Linux for i386 architecture?
Are there any good ways except the mac address?
Depending on your kernel, the DMI information may be available via sysfs.
Try those:
# cat /sys/class/dmi/id/board_serial
xxxxxxxxxxxxxxx
# cat /sys/class/dmi/id/product_uuid
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
or using a tool
# dmidecode -s baseboard-serial-number
...
# dmidecode -s system-uuid
...
On modern machines with systemd: machine id is created by systemd-machine-id-setup. The location of machine id is documented - in freedesktop machine-id and man machine-id and machine id has a more standardized format - see RFC4122. Just:
cat /etc/machine-id
You can use lshal. This needs hal (apt-get install hal or yum install hal) to be installed first. This way you can access all the info of dmidecode without root permissions.
A non-root equivalent of
# dmidecode | grep -i uuid
will be
$ lshal |grep -i system.hardware.uuid
And similarly other info as per your needs.
A simple and portable way of computing your own sysid may be to serialize uname(), gethostid() and some inodes like /home or your application homedir (obtained with stat()) etc. in a string and hash It.
Related
I have been recently working on a project named: arch loop, which is an automated installer for Arch Linux. I have seen a few installers and scripts to make Arch installation easier, but I am someone who installs Arch Linux, more than three times a day, so following the Arch-way takes a long time and constantly requires user interaction.
The Problem:
The password is, the information about non-root user is to be created is taken before itself, and when the appropriate time comes, we will be using the following command:
arch-chroot /mnt useradd -m -g users -G wheel -s /usr/bin/bash archuser
arch-chroot /mnt bash -c "echo -e 'password\npassword\n' | passwd
arch-chroot /mnt bash -c "echo -e 'rootpassword\nrootpassword\n' | passwd root
to send the password to passwd binary in the chroot system. But I don't know why it does not work. When the password is being verified by the sudo command after the installation is finished. The password seems to be perfectly working. But when tried to log in with the non-root user from tty, the password seems to be incorrect.
Things I Have Already Tried:
Manually encrypting the provided password with the below code and passing it to the useradd binary with -p option:
perl -e 'print crypt("password", "\$6\$SALTsalt\$") . "\n"'"
Please guide me on how to set a user's provided password at a later time, without requiring any user interaction.
Thank You :)
There exists the chpasswd command. It is just there only to make passwd available in batch scripts. Just do:
echo "root:rootpassword" | arch-chroot /mnt chpasswd
or maybe better, without the need for mount -o bind the sys proc and dev directories:
echo "root:rootpassword" | chpasswd -R /mnt
#subjective: Sorry for the opinion, the project looks ok, however much more work is to be done. I guess the aim is to bring Archlinux closer to "normal" users. However, I don't like the choose of python for the project. Going with plain POSIX sh would make this available for all. I don't like hardcoded partitions, mlocate (do you really use mlocate?), multiple arch-chroot calls where you could just do a single big script, not handling os.system error codes (!), multiple pacman calls without even -Sy (!) (pacman can fail if upstream updates the repos), and few more things I don't like. Except for that, nice python abstraction and cool aim. I remember the old archlinux installation scripts few (or more) years ago, they were nice, however I think used commands themselves anyway. Good luck.
The way as below works for Ubuntu, I think it should work for Arch too.
First, you should have had a machine, which has installed the Arch. Then you add the user that you need with the two commands: useradd and passwd. After that, you could cat /etc/shadow | grep [username] to get the information of the password of the user added by you, it should be a string, let's say it is XXX.
Now, on your target system, after arch-chroot /mnt useradd -m -g users -G wheel -s /usr/bin/bash archuser, you add the string coming from cat /etc/shadow | grep [username] into the /etc/shadow of the target system. The command should be like arch-chroot /mnt sed -i "XXX" /etc/shadow.
One more thing, you must make sure that the version of the Arch which you get the information of the password and the version of the target system are the same.
I am using clonezilla-live-2.6.1-11-amd64.iso
I would like to change the default section when booting off the live USB to perform full backups of the whole drive. for example:
on screen "Mount Clonezilla image directory" I would like to change the default from local_dev to use samba_server
on screen "Mount Samba server" I would like to change the default from 192.168.1.1 to 192.168.1.2
on screen "Mount Samba server" account change the default administrator to clonezilla
When I enter the items in
/syslinux/syslinux.cfg
.
ocs_repository="smb://clonezilla:password#192.168.1.2/zilla/
the menu's still ask me the default address of 192.18.1.1 and username administrator
so it appears I am not understanding the documentation. Does anyone have an example cfg?
I have delved into customizing "LiveISO's" and CloneZilla specifically so I will give a general idea of how I would attack this.
Looking at my notes this is all I had. To enable SSH Deamon I would unpack the ISO, edit the following and repack the iso using mksquashfs.
Eg:
Preparing to unpack ISO:
sudo apt-get install -y squashfs-tools
Copy iso to /tmp & rename live.iso
mkdir /tmp/mnt
sudo mount -o loop /tmp/live.iso /tmp/mnt
sudo find /tmp/mnt \( -name '*.squashfs' -o -name "*.SQFS" \) -exec unsquashfs -d /tmp/squashfs-root/ {} \;
sudo umount /tmp/mnt
sudo rm /tmp/mnt -R
cd /tmp/squashfs-root
This leaves you with:
/tmp/live.iso
/tmp/squashfs-root/FilesFromSquashedFS
Make Changes…..
sudo nano /tmp/squashfs-root/etc/ocs/ocs-live.conf
scroll to bottom & add:
ocs_daemon=\"ssh\"
Then Repack ISO:
cd /tmp
sudo mksquashfs /tmp/squashfs-root filesystem.squashfs
sudo rm /tmp/squashfs-root -R
This leaves you with:
/tmp/live.iso
/tmp/filesystem.squashfs
Now use an ISO editing Program to insert the filesystem.squashfs into the original ISO making sure to use the same name as the original ISO "squasedfs" used. Sometimes it's a different extension.
The above method is quite "General" but I found some LiveOS creators have scripts for booting the OS, making changes and then creating an ISO from the running OS.
For CloneZilla this is what I have found after a quick google.
https://clonezilla.org/advanced/customized-clonezilla-live.php
Simple Version of that Link:
Create Custom Script named custom-ocs ( A sample script file /usr/share/drbl/samples/custom-ocs)
Mount /home/partimag/
Copy script to /home/partimag/ and cd to /home/partimag/
Run the following to generate ISO
ocs-iso -g en_US.UTF-8 -k NONE -s -m ./custom-ocs
For other options, please run ocs-iso -h or ocs-live-dev -h to get more info.
Another Link (https://clonezilla.org/related-articles/012_Automated_USB_thumb_drive_using_Custom/Automated_USB_thumb_drive_using_Custom.html) shows this method which seems to indicate to me that if you place a script inside the ISO and then point to it via an edited syslinux.cfg (You could edit it using either of the above methods) you can auto-run it that way. The link says to boot USB and select first menu option, but I would want it to be fully automated where if you do nothing that option is selected regardless.
Here is the edit to syslinux.cfg that he uses:
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live union=aufs noprompt noprompt ocs_live_run="/live/image/live/custom-ocs" ocs_live_extra_param="" ocs_live_keymap="NONE" ocs_live_batch="yes" ocs_lang="en_US.UTF-8" vga=791 ip=frommedia nolocales
Note: ocs_live_run="/live/image/live/custom-ocs" This to me means run this script after booting, but I haven't tested/messed with CloneZilla in a while.
Personal Opinion: I love Parted Magic but some people don't like that it has some weird licensing now and isn't really free, but old 2013 version can be found and/or buy it for like $10. It has CloneZilla built in and also an MKISO script for making an ISO out of the booted/edited/LiveOS, but again, I generally would unpack the ISO using squashfs and then repack and inject into ISO.
Here are my links to what I've done customizing "LiveISO's". My final project years ago was a "Parted Magic" LiveISO that booted, started a PWD protected VNC sessions + ssh and e-mailed me the DHCP IP address. (I had hit and miss results with the e-mail portion, but depending on your setup you could use static IP or check router for DHCP IP address)
https://www.freesoftwareservers.com/display/FREES/Customize+LiveISO%27s
You can indeed have your Samba share automatically pre-mounted by using ocs_repository= in your vmlinuz kernel boot arguments.
However, it needs to be in the right boot file.
According to the boot parameters documentation, the relevant file is one of:
/syslinux/isolinux.cfg when booting from CD on a MBR machine
/syslinux/syslinux.cfg when booting from USB flash drive on a MBR machine
/boot/grub/grub.cfg when booting from a uEFI machine
/tftpboot/pxelinux.cfg/default or similar on your PXE server, when booting from PXE on a MBR machine
/tftpboot/grub/grub.cfg or similar on your PXE server, when booting from a uEFI netboot machine
Depending on your Samba server, you might also need to specify the SMB version to be used. From the same documentation page:
To assign the image repository via URI (Uniform Resource Identifier),
use "ocs_repository". URI supported in Clonezilla live:
[dev|smb|smb1|smb1.0|smb2|smb2.0|smb2.1|smb3|smb3.0|smb3.11|smb3.1.1|ssh|nfs|nfs4|http|https|ram]:[//[user:password#]host[:port]][/]path
I have an NFS_Server - NFS_Client system.
My client is mounted to an NFS_Server directory.
I want to change the attribute of NFS_Server directory's files via NFS_Client mounted directory by using Extended File Attributes (xattr).
When I tried to set an attribute from the client side, it gives the following answer:
root#ubuntu:/mnt/nfs/var/nfs# setfattr -n user.comment -v "some comment" test.txt
setfattr: nfs.txt: Permission denied
My question is:
is it possible to use Extended File Attributes via NFS?
if possible, how can I do this?
UPDATE:
Server side:
$ more /etc/exports file has:
/var/nfs 192.168.56.123(rw,sync,no_subtree_check)
Client side:
$ root#ubuntu:/# mount -t nfs
192.168.56.130:/var/nfs on /mnt/nfs/var/nfs type nfs (rw,vers=4,addr=192.168.56.130,clientaddr=192.168.56.123)
thank you...
You can use fuse_xattrs (a fuse filesystem layer) to emulate extended attributes (xattrs) on NFS shares. Basically you have to do:
mount the NFS share. e.g.: /mnt/shared_data
mount the fuse xattr layer:
$ fuse_xattrs /mnt/shared_data /mnt/shared_data_with_xattrs
Now all the files on /mnt/shared_data can be accessed on /mnt/shared_data_with_xattrs with xattrs support. The extended attributes will be stored on sidecar files. The extended attributes are not going to be stored on the server filesystem as extended attributes, they are going to be stored in sidecar files.
Sadly this is only a work-around.
disclaimer: I'm the author of fuse_xattrs.
(This article is old, but I came across this article when looking for this functionality, and it doesn't represent the current state.)
As others have mentioned, there is no support for extended attributes in NFS. However, there is significant interest in it, to the extent there is a proposed standard (RFC 8276).
All that is needed is Linux kernel version 5.9 or newer on both the server and client, then mount with NFS version 4.2 or newer. Support for extended attributes is enabled automatically when both server and client support nfs 4.2.
I have kernel version 5.15.16 on both my server and client with nfs-utils-2.5.4-r3, and it is working for me:
NFS Server /etc/exports
/ 192.168.0.42(rw,subtree_check,no_root_squash)
NFS Client /etc/fstab
192.168.0.42:/ /mnt/slowpc nfs noatime,nodiratime,noauto,hard,rsize=1048576,wsize=1048576,timeo=60,retrans=60 0 0
NFS Client
# mount | grep /mnt/slowpc
192.168.0.42:/ on /mnt/slowpc type nfs4 (rw,noatime,nodiratime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=60,retrans=60,sec=sys,local_lock=none)
# cd /mnt/slowpc/tmp
# touch file
# printf bar | attr -s foo file
Attribute "foo" set to a 3 byte value for file:
bar
# attr -l file
Attribute "foo" has a 3 byte value for file
NFS Server
# attr -l /tmp/file
Attribute "foo" has a 3 byte value for /tmp/file
At https://lwn.net/Articles/799185/ it is mentioned that the new mount option user_xattr is required. However the current nfs utilities do not support that option. Fortunately user_xattr is enabled automatically when possible.
# mount -o user_xattr /mnt/test
mount.nfs: an incorrect mount option was specified
# tail -n 1 /var/log/messages
Jan 30 02:51:08 utl01 kernel: nfs: Unknown parameter 'user_xattr'
Extended attributes are not supported by nfs.There is no handler for user attributes in nfs kernel module.For more information read RFC for nfsv4.
The NFS code in Linux 5.9 has finally presented support for user extended attributes (user xattrs).
The NFS server updates for Linux 5.9 have support for user-extended attributes on NFS. This is the functionality outlined via IETF's RFC 8276 for handling of file-system extended attributes in NFSv4. "This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects."
Source: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-NFS-Server-User-Xattr
I am using Cygwin and trying to change the group access permission with chmod, e.g.
$ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
$ chmod g= id_rsa
$ ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
But this does not work. I can change permission for user and others. Seems that the permission level for group somehow keeps the same as that of user?
I was having a similar problem to you, and I was using the NTFS filesystem, so Keith Thompson's answer didn't solve it for me.
I changed the file's group owner to the Users group:
chown :Users filename
After doing that I was able to change the group permissions to my will using chmod. In my case, since it was an RSA key for OpenSSH, I did:
chmod 700 filename
And it worked. In Cygwin you get two groups by default, the Root group and the Users group. I wanted to add another group, but I wasn't able to do it with the tools I'm used to use on Linux. For that reason I just used the Users group.
Cygwin doesn't like files to be owned by groups that it doesn't know.
Unfortunately, that happens quite often in Cygwin, especially if your PC is in a Windows domain where things keep changing.
I also synchronise my files between two PCs, via an external drive, and the uids/gids are different between the different PCs, so this is a source of problems.
If you do ls -l and see a numeric group id instead of a group name, it means Cygwin doesn't know the gid - i.e. it's not in /etc/group, and Cygwin can't query it from Windows either. You can confirm this by running getent group <gid>, where <gid> is the numeric group id.
To fix it, you can either use chgrp to change the group for all affected files/directories, as described in the accepted answer above, or create an entry for the unknown gid in /etc/group, with any unused group name (e.g. Users2).
After doing this, it may be necessary to close all of your Cygwin windows and then re-open them.
An experiment shows that chmod does work correctly to change group permissions under Cygwin.
The experiment used a file on an NTFS partition. Cygwin implements a POSIX layer on top of Windows, but it still ultimately uses the features of Windows itself, and of the particular filesystem implementation.
On modern versions of Windows, most hard drives are formatted to use NTFS, which provides enough support for chmod. But external USB drives typically use FAT32, which doesn't have the same abilities to represent permissions. The Cygwin layer fakes POSIX semantics as well as it can, but there's only so much it can do.
Try
$ df -T .
If it indicates that you're using a FAT32 filesystem, that's probably the problem. The solution would be to store the file on an NTFS filesystem instead. A file named id_dsa is probably an SSH private key, and it needs to be stored in $HOME/.ssh anyway.
Is your home directory on a FAT32 partition? As I recall, recent versions of Windows ("recent" meaning the last 10 or more years) are able to convert FAT32 filesystems to NTFS.
The remainder of this answer was in response to the original version of the question, which had a typo in the chmod command.
Cygwin uses the GNU Coreutils version of chmod. This,
chmod g=0 fileName
is not the correct syntax. I get:
$ chmod g=0 fileName
chmod: invalid mode: `g=0'
Try `chmod --help' for more information.
(This is on Linux, not Cygwin, but it should be the same.)
To turn off all group permissions, this should work:
$ chmod g= fileName
$ ls -l fileName
-rw----r-- 1 kst kst 0 Jun 13 10:31 fileName
To see the chmod documentation:
$ info coreutils chmod
To see the documentation on symbolic file mode:
$ info coreutils Symbolic
The format of symbolic modes is:
[ugoa...][+-=]PERMS...[,...]
where PERMS is either zero or more letters from the set 'rwxXst', or a
single letter from the set 'ugo'.
Like previous answers, not recognized groups cause such issues. It mostly happens in Windows Domains.
The easiest way to fix it is regenerate your /etc/passwd and /etc/group files (parameter -d is needed for domain users):
mkpasswd -l -d > /etc/passwd
mkgroup -l -d > /etc/group
Close and launch Cygwin again.
This is a very annoying issue for me. In my case user135348's solution worked best. The biggest issue with the chown :Users -R approach is that every time a new file is created, it will be assigned to the unknown gid 1049120. It's very frustrating to keep changing file gid.
I tried mkgroup too, but in my case it didn't work: My gid is 1049120.
Based on the rules explained in Mapping Windows SIDs to POSIX uid/gid values : : 0x100000 offset is used for account from the machine's primary domain.
Trying to remove the same offset from 1049120, you get 544, which is built-in Administrators group's RID.
This account is not a member of the local Administrators group; we use SuRun to grant administrator rights without giving out credentials. In this case, mkgroup failed to generate all the possible gids.
Editing the group file and adding a customized group name seems always to fix the issue easily.
I had this issue when working remotely from the Domain and using cygserver.
Running ls -l showed a numeric group id instead of a group name.
I stopped cygserver, net stop "CYGWIN cygserver, and other Cygwin processes, then ran the ls -l again, and group names were then displayed correctly.
I guess cygserver was holding incomplete domain group information.
After restarting cygserver the system continued to work correctly.
#!/bin/bash
find . |while read obj; do
if [[ -d "$obj" ]]; then
setfacl --set "user::rwx,group::r-x,other::r-x" "${obj}"
elif [[ -f "$obj" ]]; then
setfacl --set "user::rw-,group::r--,other::r--" "${obj}"
fi
done
You must specify the group name on the Windows system which your user belongs to.
So I just did this:
chown -R ONEX:Users ~/*
You can find your user name and group here:
I'd like to be able to detect which particular Linux flavor is installed on a computer, e.g. Ubuntu vs Fedora, via a command line command.
Some people recommend uname -a, but that only reports the kernel version.
Try the below command....
It worked for me...
cat /proc/version
Once you know that you are running Red Hat for example, you can get to the point with:
cat /etc/redhat-release
Or on Debian:
cat /etc/debian_version
or in general :
cat /etc/*-release
Also you could use the following command
cat /etc/issue
For displaying details including release and codename of the distro
lsb_release -a
You can try:
echo $(lsb_release -si)
Try hostnamectl. It lists the operating system, CPE OS Name, Kernel, Architecture, etc.