Re: [Server-devel] Attempting to re-install jabber component of XS without re-installing the entire server
On Wed, Sep 16, 2009 at 12:55 PM, Daniel Bennett dant...@gmail.com wrote: 3) Any other newbie level recommendations? If the XS is on 0.5.x, and you can make a backup, I would strongly recommend yum --enablerepo=olpcxs-testing update which will bring updates from the Fedora-9 series (good!) and will upgrade your install to the latest XS-0.6 code (which is not yet formally released, but is significantly better than 0.5.x). This brings in a lot of enhancements, should not be a very large download (though maybe the Fedora-9 updates are a bit bulky). The main update affecting you is that it includes the new ejabberd that does everything magically. Once yum update is complete, you need to rerun your domain_config command. Just once. And reboot. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] timestamps on backups
Hello, I'm not sure if anybody has noticed this yet but after doing a backup, it seems the datestamps on the backup page are wrong. For instance, after a recent backup the backup page in moodle says that the last backup was 4 hours ago even though monitoring the cron logs show that it has just completed a backup. Even weirder, moodle claims that some backups are 40 years old ! :-) I am using XS on 0.6d5 and Sugar on a Stick. Is there something about time zones and time synchronization that we need to be aware of with regards to backups. Thanks, Hamilton ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Troubles running F9 mock chroot under F11
On Wed, 2009-09-16 at 10:32 +0545, Daniel Drake wrote:
2009/9/15 Jerry Vonau jvo...@shaw.ca:
Are you just adding rpms to the install media? Or are you trying
something more difficult? I have a process in mind if you're just adding
rpms to the mix...
Just adding RPMs would be enough, but also we're customizing the
kickstart file a little.
That should be do-able using mkslim (read it first) from xs-livecd's git
repo, along with my idea to use a pre-configured updates repo on the
iso.
http://lists.laptop.org/pipermail/server-devel/2009-February/002937.html
You would create an overlay tree in lets say /tmp/xsupdates/, this
will hold what files you want to add/change on the iso. Now just make a
tree for the files in /tmp/xsupdates/. Create a directory updates,
populate it with rpms and run createrepo against it. If you wish to
replace/add a file on the iso, just have them be in the same place in
the xsupdates directory, as it would be on the iso. eg: xsupdates/ks.cfg
xsupdates/isolinux/isolinux.cfg. Then call
mkslim path to iso output dir /tmp/xsupdates
Remember to add the repo line to the kickstart file or add them as a
boot argument, for usb:
repo --name=updates --baseurl=file:///mnt/isodir/updates
for cdrom:
repo --name=updates --baseurl=file:///mnt/stage2/updates
The usb method is tested, while I have not tested the cdrom iso
However, I see that the older buildinstall(s) are not present any
more(?)! (File a bug I guess) If you were to add the buildinstall from
F9's anaconda in revisor's script directory as F9-buildinstall, then the
buildinstall from F9 should be used instead of the one on the host
system.
I did that and it now fails at a later point. I first had to modify pungi.py
+buildinstall.append('--output')
buildinstall.append(self.topdir)
and the end result is:
Linking in release notes:
100.0%
Size of the installation tree is 518 MB
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/revisor/__init__.py, line 528, in
run
self.base.run()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 106, in run
self.cli.run()
File /usr/lib/python2.6/site-packages/revisor/cli.py, line 44, in run
self.base.lift_off()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 867, in
lift_off
self.buildInstallationMedia()
File /usr/lib/python2.6/site-packages/revisor/base.py, line 1478,
in buildInstallationMedia
f = open(os.path.join(mypungi.topdir,isolinux,isolinux.cfg),rw+)
IOError: [Errno 2] No such file or directory:
'/var/tmp/revisor-pungi/0.5.2/xs-f9-i386/i386/os/isolinux/isolinux.cfg'
Traceback occurred, please report a bug at http://fedorahosted.org/revisor
The size should be more like 850mb.
Did you have any luck in your own experiment?
No, I stopped when it bombed out, had to do my real work, must of been
at the point you got past with the patched pungi.py.
Jerry
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] timestamps on backups
On Wed, Sep 16, 2009 at 5:37 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Sep 16, 2009 at 2:28 PM, Hamilton Chua hamilton.c...@gmail.com wrote: I'm not sure if anybody has noticed this yet but after doing a backup, it seems the datestamps on the backup page are wrong. We might need more detail than that if we're to understand the situation :-) Is there something about time zones and time synchronization that we need to be aware of with regards to backups. Yes, the utc time on all machines should make sense. So do date --utc on XS and on the laptops involved to make sure all players are in the same decade. This has been tested with machines on different TZs so it should work. As long as utc agrees across machines. -- martin.langh...@gmail.com http://lists.laptop.org/listinfo/server-devel The two numbers 4 hours and 40 years are almost telling. Linux keeps time as seconds from midnight January 1, 1970 12:00:00 GMT. Today GMT (Greenwich Mean Time) has been replaced by UTS (Coordinated Universal Time) which is GMT done better with atomic clocks. Since you are using XS on 0.6d5 and Sugar on a Stick the system gets the initial time of day (date) from the local hardware clock. A unix/Linux system default sets the local hardware clock to UTS while windows sets it to local time. Depending on daylight savings time in (say) Oklahoma four hours looks like a Windows system setting the hardware time of day. Since Linux can be configured to play nice with windows and set the hardware clock to local time windows is not always the issue in possiblly confusing the offset from GMT/UTS. The 40 years is very close to the beginnig of unix time (zero seconds) and can be seen on a confused local time of day clock. NTP (network time protocol) tools can be used to set the time of day on a network connected system to the correct UTS time. Local time is computed based on UTS and an offset time zone. Since all binary time stamps are UTS different users can set different timezone values in their environment and the system will do the 'right' thing. See: date date --uts date -u (export TZ=Europe/Paris;date;date-u) # touch /tmp/now stat /tmp/now (export TZ=Europe/Paris; stat now) -- T o m M i t c h e l l mitch-at-niftyegg-dot-com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
