Fatdog64-630rc1 (16 Oct 2013) [CLOSED]

A home for all kinds of Puppy related projects
Message
Author
User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

Fatdog64-630rc1 (16 Oct 2013) internationalization

#181 Post by L18L »

bug fix for package-manager:

/usr/sbin/fatdog-package-manager.sh (mark was nor working in installed packages)

/usr/sbin/fatdog-package-manager.sh.xml (some translatable=yes added)

QuickApps internationalized using "puppy's official method" t12s
translated using very latest momanager.

BTW, these 2 are my favorite Fatdog apps :D

QuickApps internationalized using t12s method

Code: Select all

#!/bin/sh
# Quick Apps - create shortcut to often used applications
# Copyright (C) James Budiono 2012
# License: GNU GPL Version 3 or later
#
#131215 Internationalization
#131216 t12s version

export OUTPUT_CHARSET=UTF-8
[ "$LC_MESSAGES" ] && LANG=$LC_MESSAGES # for --calendar and --timebox
export TEXTDOMAIN=fd-control-panel

T=/usr/share/locales # TEXTDOMAINDIR
# a one-liner to find existing translation file LOCALES allowing 'dialects'
[ ! -f ${T}/${LANG%.*}/${TEXTDOMAIN} ] && LOCALES=${T}/${LANG%_*}/${TEXTDOMAIN} || LOCALES=${T}/${LANG%.*}/${TEXTDOMAIN}

[ -f $LOCALES ] && . $LOCALES # (re)load translation file (when using variables)


### configuration
APPTITLE="${_M_15:-QuickApps}"
APPICON=/usr/share/midi-icons/go48.png	# temporary icon
QUICKAPPS_HOME=$HOME/QuickApps
DESKTOP_FILES_DIR=/usr/share/applications
REBUILD_LINK="0-${_M_17:-Finish-Configuration}"
INDEX_FILE=.apps

##################### helper #####################

create_quickapps() {
	# if already exist, do nothing
	[ -d "$QUICKAPPS_HOME" ] && return
	
	# otherwise, create it
	mkdir -p "$QUICKAPPS_HOME"
	ln -sfT $(readlink -f "$0") "$QUICKAPPS_HOME/AppRun"
	ln -sfT $(readlink -f "$0") "$QUICKAPPS_HOME/$REBUILD_LINK"
	
	# create AppInfo.xml
	cat > "$QUICKAPPS_HOME/AppInfo.xml" <<EOF
<?xml version="1.0"?>
<AppInfo>
  <Summary>$APPTITLE</Summary>
  <About>
    <Purpose>${_M_19:-Application Launcher - create shortcuts for often-used applications}</Purpose>
    <Version>1.0</Version>
    <Authors>James Budiono</Authors>
    <License>GNU General Public License Version 3 or Later</License>
  </About>
  <AppMenu>
    <Item option="configure" icon="gtk-preferences">
      <Label>${_M_20:-Add/remove application shortcuts}</Label>
    </Item>
  </AppMenu>
</AppInfo>		
EOF
	ln -sfT "$APPICON" "$QUICKAPPS_HOME/.DirIcon"
}

launch_app() {
	fatdog-control-panel.sh "$APPTITLE" "$QUICKAPPS_HOME/$INDEX_FILE"
}

configure_app() {
	rox -d "$QUICKAPPS_HOME"
	rox -d "$DESKTOP_FILES_DIR"
	Xdialog --title "$APPTITLE" --left --infobox "
${_M_13:-Two folders have been opened. One is the QuickApps folder, the other one is the "All applications folder".} 
${_M_12:-You can identify them by looking at the window title. To add a shortcut, follow these three easy steps:}

1. ${_M_18:-Create a new folder in the QuickApps folder.} 
   `gettext "This new folder serves as 'Category' and will appear as a tab in the QuickApps."`
   
2. ${:M_:-From the 'All applications folder', select then drag and drop the applications you want 
   into the 'Category' folder you created in step 1. Choose 'Link' when asked.}
   
3. ${_M_21:-Repeat step 1 and 2 as necessary. When done, click $REBUILD_LINK on the QuickApps folder.} 

${_M_11:-Your QuickApps is available from your HOME folder.}
" 0 0 90000
}

###_:-Repeat step 1 and 2 as necessary. When done, click ${REBUILD_LINK} on the QuickApps folder.} 
### TODO avoid failure from ${} inside $ { _ M _ * }

rebuild_app() {
	rox -D "$QUICKAPPS_HOME"
	rox -D "$DESKTOP_FILES_DIR"
	cd "$QUICKAPPS_HOME"
	rm $INDEX_FILE 2> /dev/null
	tab_count=0
	find . -maxdepth 1 -type d | sed '1 d; s_\./__' | while read p; do
		tab_count=$((tab_count + 1))
		{ 
			echo -n TAB$tab_count=\'$p\| 
			ls "$p" | sed 's/.desktop$//' | tr '\n' ' '
			echo \' 
		} >> $INDEX_FILE
	done
}

############# main ##############
# check how we're launched - directly or as rox app?
case $0 in 
	*AppRun) # as rox app
		case $1 in
			"") 		launch_app ;;
			configure)	configure_app ;;
		esac ;;
	
	*$REBUILD_LINK) # to finish configuration
		rebuild_app ;;	# as "
		
	*)	# as standalone app - do configure
		create_quickapps; exec "$QUICKAPPS_HOME/AppRun" configure ;; 
esac

Momanager has 2 "hello world" samples , one for gettext and one for t12s to play with....
Attachments
momanager.png
(39.24 KiB) Downloaded 1493 times
fatdog-package-manager.sh.xml.gz
save to /usr/sbin/fatdog-package-manager.sh.xml
(43.99 KiB) Downloaded 835 times
fatdog-package-manager.sh.gz
save to /usr/sbin/fatdog-package-manager.sh
(31.62 KiB) Downloaded 656 times

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#182 Post by jamesbond »

L18L,

Thanks for all these. I'm looking at your changes and I have a few questions.
1. For package-manager - where can I find this "gettext.sh"?
2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?

cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

Fatdog64-630rc1 (16 Oct 2013) internationalization

#183 Post by L18L »

jamesbond wrote:1. For package-manager - where can I find this "gettext.sh"?
locate found it here:

Code: Select all

# locate gettext.sh | grep pup_ro
/aufs/pup_ro10/usr/bin/gettext.sh
#
BTW, I had appended

Code: Select all

# update database for locate
updatedb &
to /etc/rc.d/rc.local
but it did not work, my 1st try was:

Code: Select all

# locate gettext.sh
locate: warning: database `/var/state/locatedb' is more than 8 days old (actual age is 21,6 days)
/aufs/devsave/bootupi18n/puppyrcd_i18n/usr/bin/gettext.sh
/aufs/devsave/dotpup_i18n/usr/bin/gettext.sh
/aufs/pup_ro10/usr/bin/gettext.sh
/usr/bin/gettext.sh
#
Should I better use $HOME/Startup for this?
Last edited by L18L on Sat 21 Dec 2013, 09:34, edited 1 time in total.

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

Fatdog64-630rc1 (16 Oct 2013) internationalization

#184 Post by L18L »

jamesbond wrote:2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?
The tricky part is t12s_xgettext which does that what xgettext does:
create a portable object template file for TEXTDOMAIN At least it tries to do so....
Some rules:
1- In one line of script only one ${_M_}
2- No {} inside ${_M_:-No curly bracket here}
3- No line breaks in ${_M_}, use very long lines, activate Document>Line Wrapping in geany
4 - reload translation file before any ${_M_n:-A $variable inside message}

Adding new message: use just: ${_M_:-new message}
t12s_xgettext will insert the ID number which can be
- an existing one if the message already exists in the TEXTDOMAIN
- or otherwise a new one (last highest number + 1)

Deleting a message: it will not appear in actual TEXDOMAIN.pot

Changing a message: Don't do it. Just remove the ID and change th text, e.g.:

Code: Select all

#MESSAGE="${_M_4711:-Fatdog is just a fat dog}"
MESSAGE="${_M_:-Fatdog is my favorite operating system}"
Then the existing translation
(TEXTDOMAIN.po created by t12s_msgunfmt from translation file /usr/share/locales/<language>/TEXTDOMAIN)
is merged with the actual TEXTDOMAIN.pot by gettext tool msgmerge --no-fuzzy.

The translator will see
- the deleted message commented
- and the translation for new message - msgstr - empty
... almost no difference to working with gettext

Cheers!

I am going to change some of the other scripts to t12s method (using a shell script) maybe just for fun ...

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#185 Post by jamesbond »

L18L wrote:
jamesbond wrote:
1. For package-manager - where can I find this "gettext.sh"?
locate found it here:
Code:
# locate gettext.sh | grep pup_ro
/aufs/pup_ro10/usr/bin/gettext.sh
#

Ah, yes, of course I was being stupid - I didn't check devx. Thanks! This will have to be moved from devx to the base sfs then.

Quote:
BTW, I had appended
Code:
# update database for locate
updatedb &
to /etc/rc.d/rc.local
but it did not work, my 1st try was:
Code:
# locate gettext.sh
locate: warning: database `/var/state/locatedb' is more than 8 days old (actual age is 21,6 days)
/aufs/devsave/bootupi18n/puppyrcd_i18n/usr/bin/gettext.sh
/aufs/devsave/dotpup_i18n/usr/bin/gettext.sh
/aufs/pup_ro10/usr/bin/gettext.sh
/usr/bin/gettext.sh
#
Should I better use $HOME/Startup for this?

Someone commented in earlier post that you need to create /var/state before running updatedb.

L18L wrote:
jamesbond wrote:
2. For t12s quick-apps, how would translation be handled if in the future the application is modified (e.g. deletion of existing strings, addition of new strings (how do these ${M_xxx} gets generated), changes of existing strings)? Can mo-manager automatically re-create all these changes? I surely hope I don't have to look at them one by one?

The tricky part is t12s_xgettext which does that what xgettext does:
create a portable object template file for TEXTDOMAIN At least it tries to do so....
Some rules:
1- In one line of script only one ${_M_}
2- No {} inside ${_M_:-No curly bracket here}
3- No line breaks in ${_M_}, use very long lines, activate Document>Line Wrapping in geany
4 - reload translation file before any ${_M_n:-A $variable inside message}

Adding new message: use just: ${_M_:-new message}
t12s_xgettext will insert the ID number which can be
- an existing one if the message already exists in the TEXTDOMAIN
- or otherwise a new one (last highest number + 1)

Deleting a message: it will not appear in actual TEXDOMAIN.pot

Changing a message: Don't do it. Just remove the ID and change th text, e.g.:
Code:
#MESSAGE="${_M_4711:-Fatdog is just a fat dog}"
MESSAGE="${_M_:-Fatdog is my favorite operating system}"


Then the existing translation
(TEXTDOMAIN.po created by t12s_msgunfmt from translation file /usr/share/locales/<language>/TEXTDOMAIN)
is merged with the actual TEXTDOMAIN.pot by gettext tool msgmerge --no-fuzzy.

The translator will see
- the deleted message commented
- and the translation for new message - msgstr - empty
... almost no difference to working with gettext

This sounds good. Where does these t12s tools are, I suppose they are not part of momanager? I can put them into devx if you like.
I have one more question - the POT file created by t12s, is it compatible with POT file created by the real msgformat? (I guess not ...)

I have reviewed package-manager's script, I think the gettext method shouldn't have any impact on performance (and if it does, we can always move the slowness outside of a loop). Before you go on commmitting more time on this, which way do you reckon you want to go - gettext of t12s? Speed-wise I think t12s is faster, but gettext is the "standard" method ... I'm slightly leaning towards gettext for two reasons:
- standard
- the gtk-server uses gettext, so if the script is done by t12s that means there are *two* sets of strings to be translated.
Now, I'm not doing the translation so I'm not sure whether the last statement has any impact at all in the translation part. In anyway, I'll go with the method that you choose, but I'd rather we choose one or the other (not both).

EDIT: Package manager localisation is checked in.

EDIT: I wanted to click the quote button but pressed the Edit button and destroyed this original post. Managed to recover it but the formatting is all gone, so be it.

EDIT: Just want to say that I run some unscientific test with localised package manager, it is 2times slower and unlocalised one. Seems to be "bash" slowness - if I unset LC_MESSAGES then everything runs as fast as before (even with eval_gettext left intact)... have to find other ways to optimise it.
Last edited by jamesbond on Sun 22 Dec 2013, 17:50, edited 2 times in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

sysctl errors

#186 Post by laurentius77 »

I am trying to configure Linux kernel to prevent certain kinds of attacks using sysctl command, but I got some errors

Code: Select all

sysctl -w kernel.sysrq = 0
error: "kernel.sysrq" is an unknown key

Code: Select all

sysctl -w kernel.exec-shield=1
error: "kernel.exec-shield" is an unknown key

Code: Select all

sysctl -w net.ipv4.tcp_syncookies = 1
error: "net.ipv4.tcp_syncookies" is an unknown key

Code: Select all

sysctl -w net.ipv4.proxy_arp=1
"net.ipv4.proxy_arp" is an unknown key

Probably the settings can't be set because those functions were not enabled in FatDog64 kernel.
Is there any script available to compile and update a FatDog64 kernel? If this is not possible could be these functions enabled for the next FatDog64 distro?
Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.
Thank you!

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

Re: sysctl errors

#187 Post by jamesbond »

laurentius77 wrote:Probably the settings can't be set because those functions were not enabled in FatDog64 kernel.
Probably.
Is there any script available to compile and update a FatDog64 kernel?
Not officially. There is a document that describes how to do it, though, here (you must be logged in to see it. Just log in as anonymous user).
If this is not possible could be these functions enabled for the next FatDog64 distro?
You need to be able to tell us what they are for, and whether they are part of standard kernel or from third party patches. Then well see. That being said:

kernel.sysrq = 0 --> disable sysrq, since Fatdog isn't compiled with sysrq this is already disabled by default

kernel.exec-shield --> what's this?

net.ipv4.tcp_syncookies --> working here

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp
Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.
We do that all the time, but short on the time to write anything. Basically Fatdog's kernel stuff are stored in two places: vmlinuz, and kernel-modules.sfs. The latter contains all kernel modules, and it is located inside initrd. Here is a simplified example, in short a short 13 steps :D
1. Load one of Fatdog's kernel-source sfs. # this saves your from getting a vanilla kernel and patching it
2. cd /usr/src/linux-xxxx (xxx=latest kernel version from the sfs)
3. make oldconfig
4. make menuconfig # and make your changes
5. make bzImage modules
6. cp arch/x86/boot/bzImage /path/to/fatdog/vmlinuz # this is the kernel, copy it to your fatdog installation
7. make modules_install INSTALL_MOD_PATH=modules
8. cp -a /lib/firmware modules/lib # this copies existing firmware, add more as needed
9. mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86 -noappend # this creates the kernel-modules.sfs
10. filemnt /path/to/your/initrd # rox window will open with contents of initrd
11. # copy the new kernel-modules.sfs to that rox window
12. # click "repack-initrd" from rox window to rebuild initrd
13. Done.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Re: sysctl errors

#188 Post by laurentius77 »

jamesbond wrote:
laurentius77 wrote:Probably the settings can't be set because those functions were not enabled in FatDog64 kernel.
Probably.
Is there any script available to compile and update a FatDog64 kernel?
Not officially. There is a document that describes how to do it, though, here (you must be logged in to see it. Just log in as anonymous user).
If this is not possible could be these functions enabled for the next FatDog64 distro?
You need to be able to tell us what they are for, and whether they are part of standard kernel or from third party patches. Then well see. That being said:

kernel.sysrq = 0 --> disable sysrq, since Fatdog isn't compiled with sysrq this is already disabled by default

kernel.exec-shield --> what's this?

net.ipv4.tcp_syncookies --> working here

net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp
Anyway the possibility to compile and replace the kernel for this distro would be great. If anyone knows a good tutorial for doing this it would be a great help.
We do that all the time, but short on the time to write anything. Basically Fatdog's kernel stuff are stored in two places: vmlinuz, and kernel-modules.sfs. The latter contains all kernel modules, and it is located inside initrd. Here is a simplified example, in short a short 13 steps :D
1. Load one of Fatdog's kernel-source sfs. # this saves your from getting a vanilla kernel and patching it
2. cd /usr/src/linux-xxxx (xxx=latest kernel version from the sfs)
3. make oldconfig
4. make menuconfig # and make your changes
5. make bzImage modules
6. cp arch/x86/boot/bzImage /path/to/fatdog/vmlinuz # this is the kernel, copy it to your fatdog installation
7. make modules_install INSTALL_MOD_PATH=modules
8. cp -a /lib/firmware modules/lib # this copies existing firmware, add more as needed
9. mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86 -noappend # this creates the kernel-modules.sfs
10. filemnt /path/to/your/initrd # rox window will open with contents of initrd
11. # copy the new kernel-modules.sfs to that rox window
12. # click "repack-initrd" from rox window to rebuild initrd
13. Done.
Thank you for your patience and understanding.

kernel.sysrq = 0 --> disable sysrq, since Fatdog isn't compiled with sysrq this is already disabled by default
I understood this, I'm ok with it.
kernel.exec-shield --> what's this?
Kernel Exec Shield was created with the aim of reducing the risk of worm or other automated remote attacks on Linux systems
http://en.wikipedia.org/wiki/Exec_Shield.
So, using your great tutorial I want to enable it in FatDog64 kernel. Maybe for the next kernel in RC2 it would be integrated by default.
net.ipv4.tcp_syncookies --> working here
Tried again but the same result
error: "net.ipv4.tcp_syncookies" is an unknown key
Are you using the same kernel from FatDog64 RC1? Maybe you use a new version of kernel.
Since it helps to prevent syn flood attacks it would be great to can be enabled via sysctl. I will try to identify the setting that enables it in make menuconfig and put it in the new kernel.
net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp
I will do that, I suppose it should have the same results.
Regarding compiling a new kernel I woud like also to patch the kernel with grsecurity http://en.wikibooks.org/wiki/Grsecurity.
For this i will download a vanilla kernel and apply the patch but I should also apply FatDog64 specific patches, using unofficial Fatdog64 kernel build instructions. Do you think that Grsecurity will work for FatDog64?

Thanks, have a good day!

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#189 Post by jamesbond »

laurentius77 wrote:
kernel.exec-shield --> what's this?
Kernel Exec Shield was created with the aim of reducing the risk of worm or other automated remote attacks on Linux systems
http://en.wikipedia.org/wiki/Exec_Shield.
So, using your great tutorial I want to enable it in FatDog64 kernel. Maybe for the next kernel in RC2 it would be integrated by default.
Ah, I see. ExecShield seems to be very old, the latest patches were from 2006 and for early kernel 2.6 series.
net.ipv4.tcp_syncookies --> working here
Tried again but the same result
error: "net.ipv4.tcp_syncookies" is an unknown key
Are you using the same kernel from FatDog64 RC1? Maybe you use a new version of kernel.
I do use a newer version of the kernel (I always run the latest Fatdog version - to test it beforehand and make sure that we don't release a dud) but I don't think it makes a difference, Fatdog's kernel configs only vary slighly between versions.
Since it helps to prevent syn flood attacks t would be great to can be enabled via sysctl. I will try to identify the setting that enables it in make menuconfig and put it in the new kernel.
The setting is CONFIG_SYN_COOKIES, you can check whether it is supported by typing this: "zcat /proc/config.gz | grep SYN_COOKIES", if you see something it has already been enabled.
net.ipv4.proxy_arp --> working here if you change it to net.ipv4.conf.all.proxy_arp
I will do that, I suppose it should have the same results.
It is in fact the same thing. The kernel changes its configuration space overtime. I don't know where you get your security recommendations but they seem to be very old. Btw - enabling proxy_arp has nothing to do with security, it has everything to do with network bridging. Do you know what you're doing?
Regarding compiling a new kernel I woud like also to patch the kernel with grsecurity http://en.wikibooks.org/wiki/Grsecurity.
Go ahead and good luck! :D
For this i will download a vanilla kernel and apply the patch but I should also apply FatDog64 specific patches, using unofficial Fatdog64 kernel build instructions. Do you think that Grsecurity will work for FatDog64?
Fatdog's kernel is basically vanilla + aufs patches. Nothing else (well, sometimes we do backports patches for newer kernels, but most of the time don't). You can try applying grsecurity patches to Fatdog's kernel directly. Only if they don't work then you can try vanilla. In anycase, good luck.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

Hardened FatDog64 project?

#190 Post by laurentius77 »

Thank you for your answers.

What I am trying to do is to harden FatDog64 in order to run server applications on it. Having a server that starts as a frugal install is assuring that is not compromised. Hardening the host with a good firewall and other good security measures keep this server safe for a sufficient amount of time (ex: a few days), this period of time being enough for some projects where a server must start and run securely.

I found a project about hardening linux on http://wiki.securix.org/doku.php and http://www.securix.org and I'm trying to implement some of them in FatDog64. From what you said me some of them are deprecated.
I'm a novice in linux so it will be difficult but I hope to have some results.

Anyway the idea of hardening FatDog64 for running server applications seems ok to me because we have hundreds of puppy distros but none of them can't be used for this.
Maybe an experimented user can think about starting a project for having a hardened puppy distro, focused on security not on desktop applications.
I choose FatDog64 because is multiuser and server applications can be run as spot user, this being a great advantage.

If you have some other ideas that can satisfy these needs I will be glad to try them.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#191 Post by jamesbond »

My recommendation is to run the server virtualised. Fatdog offers many choices here.
1. VirtualBox -
2. Qemu/KVM - same as virtualbox, probably a bit faster but no GUI (shinobar used to create one long time ago, not sure whether it is still working)
3. UML - you asked for this before, did it or did it not work for you?
4. New in rc1 is LXC support (sandbox-lxc). rc2 will offer LXC with user namespaces.

cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

laurentius77
Posts: 82
Joined: Wed 30 Mar 2011, 07:02

#192 Post by laurentius77 »

jamesbond wrote:My recommendation is to run the server virtualised. Fatdog offers many choices here.
1. VirtualBox -
2. Qemu/KVM - same as virtualbox, probably a bit faster but no GUI (shinobar used to create one long time ago, not sure whether it is still working)
3. UML - you asked for this before, did it or did it not work for you?
4. New in rc1 is LXC support (sandbox-lxc). rc2 will offer LXC with user namespaces.

cheers!
I have UML working already. I coudn't start spot as default user in UML, always it starts as root. In my understanding having one server application running as root being compromised will compromise other applications fro VM also. Anyway a restart of the VM will eliminate the problem.

I'm not afraid about infecting the host distribution because I always will use in RAM mode with Puppy. I just want to secure the distro as much as I can against internet attacks. I will never use browser, or even X and I will start the distro as spot with nox. But I want to be sure that I have as much security as I can.

I applied already grsecurity patch FatDog64 sources with success and I'm trying to get a new kernel (version 3.11.4).

Thank you again, you are doing a great work.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#193 Post by jamesbond »

laurentius77 wrote:I have UML working already. I coudn't start spot as default user in UML, always it starts as root.
Ah yes, you need to customise the application startup script (ie automatically su to non-root when the app starts). You can tell start-uml.sh to run a script when UML starts up (using START_CMD) and this script can drop down to non-root and do other stuff as needed.
In my understanding having one server application running as root being compromised will compromise other applications fro VM also.
True, the trick is to run exactly ONE app in ONE VM.
I will start the distro as spot with nox.
Don't use spot. spot is root's surrogate. Create a new user (mkuser.sh or from the user manager) and use it instead.
I applied already grsecurity patch FatDog64 sources with success and I'm trying to get a new kernel (version 3.11.4).
Cool, and good luck.
Thank you again, you are doing a great work.
You're much welcome.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

fatdog
Posts: 104
Joined: Wed 17 Apr 2013, 03:12

#194 Post by fatdog »

Fatdog64 630rc2 is released. Thank you rc1 testers.
-= The Fatdog Team (kirk, jamesbond, SFR and step) =-
[url=http://murga-linux.com/puppy/viewtopic.php?p=794748#794748]Contributed Fatdog64 packages thread[/url]
This account is used for announcements only. Send PM directly to members' handle.

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

#195 Post by L18L »

Need to give some replies here:
jamesbond wrote:...This sounds good. Where does these t12s tools are, I suppose they are not part of momanager? I can put them into devx if you like.
They are part of momanager.
I have one more question - the POT file created by t12s, is it compatible with POT file created by the real msgformat? (I guess not ...)
msgid and msgstr are compatible, header and comments differ.
...Speed-wise I think t12s is faster, but gettext is the "standard" method ... I'm slightly leaning towards gettext for two reasons:
- standard
- the gtk-server uses gettext, so if the script is done by t12s that means there are *two* sets of strings to be translated.
Now, I'm not doing the translation so I'm not sure whether the last statement has any impact at all in the translation part. In anyway, I'll go with the method that you choose,
but I'd rather we choose one or the other (not both).[/quote]
Because of "not both" it is a fast decision: gettext only because of gtk-server 8)
Exception: jwm_create is sort of t12s (it is the ancestor)
BTW, puppy's fixmenus fixes menus
your replacement fixes jwm menu only.... :wink:
EDIT: Just want to say that I run some unscientific test with localised package manager, it is 2times slower and unlocalised one. Seems to be "bash" slowness - if I unset LC_MESSAGES then everything runs as fast as before (even with eval_gettext left intact)... have to find other ways to optimise it.
I have found a "test bed"

Code: Select all

### show main window and enter main loop
gtk gtk_widget_show $MAIN_WINDOW
[b]time[/b] populate_all_pkg
populate_installed_pkg
while true; do 
Maybe forget LC_MESSAGES at all
and use just
LANG=C
and
read LANG < $HOME/.fatdog/language

Using LC_MESSAGES is a little bit faster than using LANG.
15.7 sec vs. 17.1 sec on my box
only ()
It is not worth to deviate from common use in puppy: LANG only (no LC_MESSAGES)

Post Reply