Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: hiro on August 25, 2015, 09:39:34 PM
-
First time I'm trying out dcore, wondering...
root@box:~# passwd
passwd: password updated successfully
root@box:~# ls -l `which passwd`
lrwxrwxrwx 1 root root 41 Aug 26 00:39 /usr/bin/passwd -> /tmp/tcloop/openssh-server/usr/bin/passwd
Would you also use that huge openssh package with all those dependencies from debian, or is there a way to easily use the extensions from tc6 repo if they are preferred?
-
There are also other problems. Sometimes I get segfaults when passwords get queried.
-
Busybox passwd has the features dCore needs, so for now I can remove the passwd command from being installed from Debian. I will work on finding the issue in the passwd package.
I import and use the ssh package from Debian. For things that the Debian versions either are not available or do not work, we keep a prebuilt section. We can't mix the tcz repo alongside our prebuilt or Debian repo packages.
-
removing debian password sounds like the right thing to me, yeah.
i'm curious whether i'm really the only one who experienced these problems due to fear of having done something wrong...
-
We use our own startup scripts to deal with problems that the native script does not take care of. Or, we can upload a prebuilt version of the package, or delete/add files. Thanks for testing, the more folks that use dCore the more issues and solutions we will find.
-
I haven't upgraded yet, so I'm not sure if you fixed it already. Either way I would really like to understand what's going on.
When I run su the one being used is /tmp/tcloop/openssh-server/bin/su
When I do that I don't get a password prompt. It always succeeds for every user.
I don't think this should happen :D
-
I see the issue, will fix it tonight.
-
should be fixed, please re-import any SCEs that contain the passwd package and test.
-
openssh-server now has as dependencies:
adduser
coreutils
debconf
debianutils
dpkg
findutils
gcc-4.9-base
init-system-helpers
initscripts
insserv
libacl1
libattr1
libaudit-common
libaudit1
libblkid1
libbsd0
libbz2-1.0
libc6
libcomerr2
libedit2
libgcc1
libgssapi-krb5-2
libk5crypto3
libkeyutils1
libkrb5-3
libkrb5support0
libmount1
libncurses5
libncursesw5
libpam-modules
libpam-runtime
libpam0g
libpcre3
libprocps3
libselinux1
libsemanage-common
libsemanage1
libsepol1
libsmartcols1
libssl1.0.0
libtinfo5
libudev1
libustr-1.0-1
libuuid1
libwrap0
login
lsb-base
mount
ncurses-base
openssh-client
openssh-server
openssh-sftp-server
passwd
perl-base
procps
sensible-utils
startpar
sysv-rc
sysvinit-utils
zlib1g
Seems like debian needs a lot of babysitting from you guys to do anything :D
Have to reboot the system an other time to test. It's running stuff I need right this moment.
-
But out of 20,000+ packages, very few need any adjustment on our end as most just work. And once adjusted, then the fix applies to all dCore ports and across many releases. The work is by far done by them, not me. :-)
-
yeah, all those graphical apps that people use are probably fine as long as the base works.
I like not having to force all this software to fit into tinycorelinux package repos, seems like duplicated effort especially when every package anyways depends on every other package (not distribution-specific, but typical for big programs)
it does freak me out though that a basic program like openssh gets all those dependencies by default in debian. dcore showcases that fact quite well. so perhaps it's helpful in rising awareness :P
-
I see the issue, will fix it tonight.
can you tell me what you saw/fixed?
I rebooted my server now but i still have the old problem.
Should running sce-update before rebooting have been enough?
-
I moved to using busybox passwd.
What is the output of the command -
which passwd
-
$ ls -l `which passwd`
lrwxrwxrwx 1 root root 41 Sep 22 22:26 /usr/bin/passwd -> /tmp/tcloop/openssh-server/usr/bin/passwd
also, even more concerning:
$ ls -l `which su`
lrwxrwxrwx 1 root root 33 Sep 22 22:26 /bin/su -> /tmp/tcloop/openssh-server/bin/su
Can you explain what's technically happening here? Why is the debian su failing to protect us in any way and doesn't ask for a password?
-
I also noticed that when I do sce-update -a I keep on getting an update of
libgnutls-deb0-28 debian jessie main
It results in this to be downloaded every time over again:
Connecting to security.debian.org (212.211.132.250:80)
libgnutls-deb0-28_3. 100% |******************************************************************************************************************************************************************| 692k 0:00:00 ETA
Merging libgnutls-deb0-28
-
The sudoers file in dCore is what determines whether su asks for a password. It would break the dCore script routines if that was changed.
Have you run "sce-update -a" recently and rebooted?
And are you using the latest dCore release?
-
yes, i did. i updated again now just to make sure and rebooted again and still i get the same behavior for both passwd and su.
can you not reproduce this?
i mean... put dcore x86 into a vm, load openssh package and run su as any user (without changing sudoers file) and you'll get root access.
i now installed a special VM.
then i only do sce-import openssh and sce-load openssh
and any user can use su to get root without password.
also why would su use the sudoers file that should be for sudo?
-
Fixed the su command, please download a new dCore x86 from the release area. Using the busybox version to ask for a password, though by design 'sudo su' does not need a password.
On my box, /bb/passwd is used as passwd as expected.
I imported libgnutls-deb0-28 and then ran 'sce-update libgnutls-deb0-28' and it said the package was up to date.
I am using a real install on a standard PC, what virtual machine are you using?
-
Seems like sce-update would only detect libgnutls-deb0-28 as outdated with the previous release from august.
Perhaps you have /bb in the front of your path? Does your /bin/passwd file get deleted?
I can't find a su.deb2sce in deb2sce.tar.gz, but I do indeed see a passwd.deb2sce, still it seems that it doesn't get executed successfully?
*edit: I realise there is no su.deb, it comes from login.deb. Of course the tce.installed/login file doesn't delete the su file.
What change did you make? I can't see anything in the git log.
*I tried to debug a bit using dpkg-deb (which is installed, but "dpkg-deb: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory")
after installing liblzma5 I get
dpkg-deb -c coreutils_8.23-4_i386.deb
tar: unrecognized option '--warning=no-timestamp'
I also again have problems posting to the forum multiple times in sequence:
We're sorry, but we could not fulfill your request for /index.php/board,66/action,post2.html on this server.
You do not have permission to access this server. Before trying again, close your browser, run anti-virus and anti-spyware software and remove any viruses and spyware from your computer.
Your technical support key is: b01f-fd46-b40c-8ddc
*also I'm not getting mail notifications any more when someone replies.
-
Below is my $PATH
tc@box:~$ echo $PATH
/home/tc/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/bb:/etc/sysconfig/tcedir/ondemand
tc@box:~$
/bin/passwd does get deleted from it's startup script.
/bin/su has been added in base as a symlink to busybox and does not get overwritten by imported packages. Git is for changes in the dCore scripts, so base file changes don't get in there. But I will be more detailed in the release and release candidates thread.
Debian tools are not fully supported, we track and manipulate packages and files much the same as Core but with a different source of binaries.
It sounds like Debian tar is not installed so busybox tar is being used. I can add those deps so if there is functionality of dpkg-deb folks can use it.
Sorry, I can't help with the forum issues you are seeing.
-
It's strange that the passwd didn't get overwritten in the older .iso.
Now with last .iso everything is as you say. passwd gets deleted while a link to busybox su gets created.
One thing is still strange with busybox su: if you put no password su segfaults on enter.
-
When I enter su and just enter at the password prompt, it just replies "incorrect password" on my box.
-
it happens when the password is not set (* or ! in /etc/shadow)
-
It's strange. I updated my other server to latest initramfs and it seems like there the /usr/local/tce.installed/passwd didn't get run successfully, because I still have passwd pointing to the passwd provided by openssh-server.
packages have been updated using sce-update -a
Also there's a line 'rm /usr/bin/chpasswd', but it has no effect cause chpasswd and chgpasswd is in /usr/sbin/
-
Could it be that there is some bug when multiple sce have passwd and get loaded one after the other?
To support this thesis: Openssh gets loaded after lvm2 here. lvm2 also has passwd (I think there the delete must have worked).
-
Added symlinks to busybox for passwd and chpasswd in base, current changes uploaded to release candidates. Adjusted startup script for compatibility with current release.
The startup scripts for packages get run by the first SCE loaded that contains the package.
-
I consider this a temporary fix as I would like to get passwd to work like we do with other packages that need adjustments.