When using the db2setup (Wizard) to install a new version of DB2 V10.5.0.3 (or the universal fixpack V10.5.7) the installer appears to hang near the end of the Create DB2 Administration task. There is a das directory created in the /home/dasusrX directory but it has no visible files. The logs show no errors. Manually trying to create the DAS also hangs using dascrt -u dasusrX
In the console where I launched the db2setup I found I needed to enter the dasusrX password a couple of times. There is no prompt displayed. I believe the system also hangs during the Configuring DB2 instances task and luckily I used the same password for other users so I entered it there as well to complete the install.
I figured this out running the dascrt -d -u dasusrX and saw it hung at the su dasusrX -c /bin/pwd command and when I tried that command manually, it propmted for the dasusrX password. This may be a unique situation for our server set up as root is accessible only via sudo -i so perhaps in other situations there would be no prompt for dasusrX password when using su as root.
Related
I have a remote headless server (MacOS BigSur 11.3.1). When I log in via ssh (with either the root user or regular user), I am unable to save to the crontab.
When I use the following command:
% crontab -e
I can see a cronjob that I saved when I was logged in locally (not via ssh). After editing and exiting the crontab, I get the following error:
crontab: installing new crontab
crontab: tmp/tmp.1028: Operation not permitted
crontab: edits left in /tmp/crontab.kKYx3tt4c1
While logged into ssh, I have instead tried to edit the crontab with this command:
% sudo crontab -e
To my surprise, the cronjob that I saved when logged in locally is not listed. It is as if it is a different crontab for a different user. In any case, I can't save to the crontab when using sudo either. It gives the exact same error as above.
I have followed the advice of a few internet posts suggesting allowing the cron and sshd executables "Full Disk Access" through the Mac System Preferences. However, the same error persists.
I'm not sure what to try next.
So the issue was solved by giving sshd-keygen-wrapper full disk access. Don't ask me why that needs it, but it is working now. I hope this helps anyone with the same issue.
Is it possible to enforce that a user have to change the password after the next login in Alpine Linux?
Background:
We deploy a bunch of Alpine Linux VMs for IaaS. We use packer for that. During the configuration all machines gets the same password (from the script).
Links for other Linux distributions
tecmint.com
cybercity.biz
I have tried chage -d 0 {user-name} here is the result that alpine do not know the command. The package manager (apk add), was not able to find the package.
Also I tried passwd --expire {user-name}. passwd is a valid command but the option -e or --expire is invalid.
chage is part of the shadow package, so installing this package should work for you:
https://pkgs.alpinelinux.org/contents?file=chage&path=&name=&branch=edge&repo=community&arch=x86_64
I am pretty new at php and ubuntu. I have 2 servers set up, one for development and one for staging. On the dev machine I can use the at command without a problem, but on staging I get a permissions error. The at.deny (and at.allow) files are identical, so it must be another permissions issue.
Any clues?
I see that on the staging server I can only use at command as root. How can I fix this to be able to use the at command as www-data? Again... I checked the at.allow and at.deny files ... they are not the problem here.
1) Check if you have file /etc/at.allow.
If it exists - just add your user in new line.
If not exists - try to find your user in /etc/at.deny and remove/comment it.
2) Restart "at" daemon:
sudo atd restart
3) Check:
at -l
or
sudo -u myuser at -l
The error should not be output.
I have a chef recipe that runs a chocolatey install for Microsoft SQL server. From my workbench when I run
knife winrm [IP] 'chef-client -o "recipe[NetDevMachine::default]"' -m -x 'domain\myuser'
over a node it fails with the error:
532459699 or sometimes 2022834173 or 2057043966
However if I log onto the VM as the same user and locally run
chef-client -o "recipe[NetDevMachine::default]"
It works. Does anyone know what the difference is between running chef-client locally and running it remotely from the workbench? What does chef-client do differently here? Both are pulling the recipe from the same chef-server repo.
Additional Details
I am using the same user for both
I have successfully run other recipes from the workstation, it's just this MicrosoftSQLServer install that's not working
running "knife winrm [IP] 'choco install MicrosoftSQLServer' -m -x 'domain\myuser' also does not work
Recipe contents:
powershell_script "choco install MicrosoftSQLServer2014" do
code <<-EOH
choco install MicrosoftSQLServer2014
EOH
end
Error:
[ERROR] Running C:\Users\myuser\AppData\Local\Temp\MicrosoftSQLServer2014\setup.exe with
/QUIET /IACCEPTSQLSERVERLICENSETERMS /ACTION=INSTALL /INSTANCENAME=MSSQLSERVER /FEATURES=SQL,TOOLS,LOCALDB
/SQLSVCACCOUNT="NT AUTHORITY\Network Service" /SQLSYSADMINACCOUNTS=BUILTIN\ADMINISTRATORS
/SKIPRULES=REBOOTREQUIREDCHECK UIMODE=AUTOADVANCE was not successful.
Exit code was '-532459699'.
Edit - the only difference I can see is that one runs in the foreground and the other doesn't. So the location of the compile chef-script is /temp/2 for the failing run. I don't know if there is a way to force chef to run in the foreground or if that will even help.
Thanks
I never got to the bottom of this and still don't understand how running the chef client remotely using knife was different from running chef client directly on the VM. Perhaps it was something to do with the handling of credentials or permissions when remotely sending commands.
But I did find that removing chocolatey and replacing it a command line silent install inside a chef powershell resource allowed me to install MSSQL.
this is what I am doing:
Creating a new server on Linode. OS is centos 6.5
Logging in as root
running the following script to add a user called shortfellow which does not have a password.
The script is:
#!/bin/bash
yum -y update
adduser shortfellow
mkdir -p /home/shortfellow/.ssh
echo "ssh-rsa REALLYLONGSSHPUBLICKEY shortfellow#example.io" >> /home/shortfellow/.ssh/authorized_keys
chmod -R 700 /home/shortfellow/.ssh
chown -R shortfellow:shortfellow /home/shortfellow/.ssh
su - shortfellow
exit
The problem is that first time when I try to ssh into the system. It does not work at all. It simply asks for the password. I hit ctrl + c and try to ssh again as the same user, it works.
this behaviour is really annoying because I am writing code to create the server programmatically and it does not work because of this silly issue.
Does anyone have any idea why this might not be working as expected?
I did /sbin/mkhomedir_helper shortfellow in the script before the exit and it works correctly after that.
I guess the issue was really that the home directory for a user is created only at login and when I tried to programmatically create this user this would not happen for some reason.