I'm trying out yocto (2.0, jethro) and I want to build an image starting from core-image-minimal. This works fine.
Every website out there mention modifying the file build/config/local.conf with (some of) my customization. For example, the target machine (through MACHINE) or some global settings (through EXTRA_IMAGE_FEATURES).
I also need to modify some specific packages and the way to do it is to create a custom layer. So far so good.
What I don't understand is how to "save" all my configuration to version control. I want everything I change to be locate in files that I can commit so that anybody else can reproduce the exact same build (or even contribute to that project). Putting almost everything in build/config/local.conf goes against that goal; the file is under a "build" directory and so I can't just clone a git repo and start the building...
Is it really the way the yocto project works? Or am I missing a different configuration file where I need to put these settings? I though I could place all these in a custom layer but it does not seem to work...
Any idea or suggestion?
Thanks!
Thanks Ross, that clarified it!
Here's some notes about my file organization which I couldn't format into a comment to your answer.
Thanks. So all my custom configurations went into meta-mylayer/conf/distro/mylayer.conf
Almost all my customization went into a layer meta-mylayer, except:
DISTRO which is set in build/conf/local.conf. This is how you tell yocto what you want to build.
MACHINE which is also set in build/conf/local.conf. The reason is that the same image/distro combination could be built for different machines and thus this can't be hard-coded for every images.
Layers are manually added to build/conf/layers.conf. That's the last bit I wish I could moved to my DISTRO or something. For now the folders are git submodules and they are added using bitbake-layers add-layer.
In general everything in your local.conf that is "your project" should be moved to your own distro configuration (MACHINE, image features, package lists). Stuff like where DL_DIR is can be moved to a common site.conf if you wish. Eventually you should end up with a local.conf which just sets DISTRO and some other personal variables.
What are the recommended steps to upgrade TYPO3 4.5 (or 6.1) to 6.2? I have a mac and my site is running on a shared Linux account.
Here's a step by step guide from my upgrading practice which I would like to share. Thanks for the guide on https://jweiland.net/typo3/vortraege/typo3camp-berlin-2014.html that has helped me a lot.
Note that these are my personal experiences which may or may not apply to your environment. Treat everything carefully.
I differentiate between "Quick" and "Long" upgrades. With "Long" upgrades, you do the upgrading twice. First, you upgrade a copy of the live site, get all extensions and templates working, and when you're ready, you declare the content freeze, re-doing the upgrade, using the files modified in the first step. For a "Quick" upgrade, you declare a content freeze right away, do the upgrade and tests, and then deploy to the test or live environment directly.
Set up the site locally
When you're ready to freeze the content (BE][adminOnly] = 0), don't forget to check if the site has user contributed content? If so, either disable the possibility to submit it, or note which tables you have to re-import after enabling the upgraded site.
Hint:
Work locally. I can only refer to using MAMP Pro (be sure to get the
pro version) on a mac. Always be aware on which site (and with which
DB) you are working, btw! And attention: OS X file system is case
insensitve, which can be a bummer when deploying to Linux (see below).
For the database administration, I prefer http://www.sequelpro.com/ to
phpMyAdmin for most tasks. It's very handy to make backups or to
quickly browse tables, although it has a few missing features in
comparison with phpMyAdmin. It is also extremely reliable for
importing dbs onto a live server - where phpMyAdmin can stall often.
Beware if [SYS][UTF8filesystem] is set: transferring files to OS X via popular (S)FTP clients like Coda or Transmit (haven't tested Cyberduck) can damage the filenames containing UTF-8 filenames. Thus all links to such files will be invalid when you deploy. Pack them into an archive befor transferring or use scp. Avoid the setting in the first place.
Create your local TYPO3 instance. It's practical if you keep an "old" and a "new" core in the same location, so you can switch between them easily by symlink. Create and connect the local database.
Hint:
If you're working on MAMP, you'll have to chown all the files (except
templates and config files of your apps (like Sublime)) to _www:_www.
I have found it useful to define some aliases for the sudo chown in
~/.bash_profile, like alias chownmamp="sudo chown -R _www:_www ."
and vice versa to your own user. Another possibility might be to
temporarily chmod 777 everything - when deploying, taking extra care
this is removed (find . -type f -exec chmod 644 {} \;find . -type d -exec chmod 755 {} \;)
Duplicate the site and the DB to keep an un-upgraded version for comparison - even after you've deployed
Init a local git repo, don't forget to add .gitignore for temp data. Commit from time to time!
Hint:
If you use different hostnames for your local and the live site,
replace them where needed. For the command line, I have found grep -rl 'www.site.ch' ./ | xargs sed -i 's/www.site.ch/www.localsite.dev/g' useful. But of course you can
do that in your IDE or editor too. Don't forget to check
realurl_conf.php and .htaccess too. For a quick run, it is also
possible to use the real hostnames, so you don't have to replace
anything (but won't be able to compare sites from the same machine).
You should now be able to log into the backend and into the install tool
Hint: On MAMP, I've had issues with $TYPO3_CONF_VARS['BE']['warning_email_addr'] which prevented logging into the install tool with an error 500, as it couldn't sent the email. Remove that setting in localconf.php for the local upgrade if it happens.
Prep the upgrade
Make a backup of files and DB. (make frequent db dumps later on too)
Important: Install tool > Database Analyser > Clear Tables: clear all caches, logs, also the history data (if that's ok with you). The less huge the database is, the smoother the upgrade will go.
Get the frontend running.
Also, make sure you have the admin Panel. It's very helpful to override TYPO3 caching and to debug performance bottlenecks. Also, you can reliably force TS rendering at every reload. Set config.admPanel = 1 in page TS, enable it in your admin user's TS by admPanel=1, and log in with the domain you will be viewing the FE from. The adminPanel only shows up if you're logged in on that domain! While you're there, also add options.clearCache.system = 1 to the admin's TS, so you can clear the system cache also when in production mode.
Install http://typo3.org/extensions/repository/view/smoothmigration and run it. Fix the issues you can fix now, e.g. UTF8 issues in the DB. Copy the remaining report and save it in a word file or similar - you can't run smoothmigration after the upgrade anymore
Go through all extensions. Do we need them at all? You can find out if a plugin is used with (for example) SELECT * FROM tt_content WHERE list_type = 'news_pi1' or by looking at all cType = 'list' entries in tt_content. If it's not used, consider removing the extension too. Or can it be replaced by a better extension, or re-built by hand / via tt_content? (For example a carousel, I'd rather not have to maintain an extension for that. But check the budget! Everything takes time.
I get rid of indexed_search, as ke_search is a very reliable alternative that is quick to set up.
Hint: with FAL, the _cli_scheduler user needs rights for every file mount you want to index with ke_search, else the indexing via scheduler will fail.
Main task: Check for extension updates. If a compatible extension update is available, do it. But first check if it works with the old and the new site: http://typo3.org/extensions/repository/view/realurl : This version works for TYPO3 4.5.0 - 6.2.999 - if it doesn't, don't update yet.
Be sure to remove realurl_clearcache, the TER version will break on 6.2
When you're done removing, uninstall all remaining local extensions. You don't have to uninstall sysexts.
in typo3conf/ext we will have a quite short list of extensions now. That is good!
Backup the db and make a DB-Compare in the install tool. CAUTION: don't touch extension data you will need for importing later on (tt_news, powermail, dam). If you dare, you can rename or remove other, 100% obsolete data.
Study the "Reports" module in the BE and take the recommended actions
If you have the patience, check for broken links on the site - they may make problems when converting to FAL.
Is there content / pages that can be deleted for sure? (E.g. ancient test pages, duplicates, etc?) Delete it if you dare.
Don't forget: Empty the trash (Module "Trash") for all pages recursively. No need to migrate deleted content. Cf. https://forge.typo3.org/issues/62360 to delete many items at once
Important: Update the reference index (in the module "DB Check"). It has to be PERFECT before the upgrade.
Make that backup...again
Do the upgrade
-> Switch the core to 6.2
Reload the backend, you will land in the install tool. To connect to the DB, you may have to enter "localhost" instead of 127.0.0.1 as prefilled
Install tool: check folder structure and system environment, make it all green. Read System Environment until the bottom: "Red" items are on the top, but "blue" items (recommended) are on the bottom (e.g. a missing system locale, which is needed if you use UTF8-Filesystem).
Hint: don't be too eager with APC, the availability check
in 6.2 isn't perfect, cf. https://forge.typo3.org/issues/64030 (you
can't use it if your shared hosting relies on suPHP).
Install tool: Run the first wizard. Just the first one. Do NOT run "Migrate all file links of RTE-enabled fields to FAL" yet.
Important: Log into the backend as admin. Go to filelist, refresh the file tree if necessary. Now set the filemounts (fileadmin...) to "Use case sensitive identifiers" in it's settings. Otherwise, you may end up with all filenames in lowercase in sys_file, which will not work on the live linux system.
Also, run the task File Abstraction Layer: Update storage indexin the scheduler and update the reference index.
Install tool: Go through the rest of the upgrade Wizards. To debug broken links that can't be migrated, use the workaround from https://forge.typo3.org/issues/64122 (6.2.10 up)
Hint: If something doesn't seem to be complete after all wizards went through, you can re-enable the upgrade wizards in LocalConfiguration.php under ['INSTALL']['wizardDone']. (Like if the whole sys_file_reference table empty and there are no images in tt_content table - remove the line for TceformsUpdateWizard, so it can run again).
Important: Install tool: All Configuration: Deactivate content adapter! Else you will be running in a slow kind of compatibility mode and not really doing the entire Upgrade.
Check "Reports". Make it all green!
Install tool: Check image rendering (I prefer GD), set fitting Configuration presets
Hint: Check typo3conf/AdditionalConfiguration.php and make sure there are no values in it that override values from LocalConfiguration.php. I've had this on a 6.1->6.2 upgrade, and thus was unable to enable error logs (the devIPmask was overridden all the time).
Main task: Update and install Extensions that have updates that were not compatible with the old core.
Hint: here are a few occasional replacements I had to make
for 6.2 compatibility:
require_once(PATH_tslib . 'class.tslib_pibase.php‘);
-> if (!class_exists('tslib_pibase')) require_once(PATH_tslib . 'class.tslib_pibase.php');
require_once(PATH_t3lib . 'class.t3lib_scbase.php‘);
-> require_once(\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('backend'). 'Classes/Module/BaseScriptClass.php‘);
t3lib_div::GPvar()
-> \TYPO3\CMS\Core\Utility\GeneralUtility::_GP()
mysql_num_rows($res)
-> GLOBALS['TYPO3_DB']->sql_num_rows($res)
t3lib_div::intInRange
-> t3lib_utility_Math::forceIntegerInRange
t3lib_div::view_array()
-> t3lib_utility_Debug::viewArray
t3lib_div::testInt
-> t3lib_utility_Math::canBeInterpretedAsInteger
EDIT: a much more comprehensive list is on https://github.com/FriendsOfTYPO3/compatibility6/blob/master/Migrations/Code/ClassAliasMap.php
Updating from DAM? Use https://github.com/b13/t3ext-dam_falmigration, following Installation and Scheduler Task and Usage. Be aware that with MAMP, you have to run MAMPs PHP from the command line, for example /Applications/MAMP/bin/php/php5.5.18/bin/php ./typo3/cli_dispatch.phpsh extbase help
Moving tt_news to tx_news? I've had an issue with the importer where not all translations were imported. There is a newer version now.
Updating Powermail? Nice, there is an updater! Thanks! I also encountered issues with translations. In one case, they could be solved by hitting the "localise" button for a form, though.
rlmp_tmplselector: either use https://github.com/jweiland-net/rlmp_tmplselector/ or move page type seletion to core's backend layout.
Hint: In the last case, take care, to select the page template in
accordance to the selected BE Layout, never use .if, always use CASE.
See With TYPO3 be_layout, how to choose frontend template correctly (performance-wise)?
Main Task: Templates have to be updated. Just a few things: New IMAGE / FILES TS, config.doctype=html5 (not html_5), replace all HTML Objects by TEXT. Use the TypoScript Object Browser (TSOB) at least check that there are no errors in TS.
If you haven't done it before ("Long" Upgrade), install extension after extension and fix what has to be fixed (google the errors). Install https://github.com/medialis/realurl_clearcache by hand if you need it.
Do you use imagemap_wizard? https://github.com/lorenzulrich/imagemap_wizard and add the css fix from https://forge.typo3.org/issues/58212
Hint:
Btw, extensions I use on all sites: realurl_clearcache,
nc_staticfilecache, sourceopt, ke_search. On most sites
(feature-based), of course: news, powermail.
Don't forget: Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer). If you have to modify content, use a simulated editor user to spot problems early.
Update Translations via the "Language" Module, so editors will get translated Backend and Extensions
Hint: Also make sure that the "page tree rights" group is properly set
up, cf http://typo3.uni-koeln.de/typo3-admin-access-default.html?&L=0
There may be problems with filenames containing special characters like umlauts, sometimes resulting in broken file links (I use Integrity or Scrutiny for mac to check the whole site), sometimes only in ugly filenames. Check and process manually (if FAL works, you can just rename them in the backend) if required.
Hint:
Here's a snippet I add to all user's userTSConfig.
Go through everything. If you have the time and budget, make the website better, use webpagetest.org to spot performance holes, clean the .htaccess, combine assets, check the page rendering times in the admin tool, update frontend dependencies, check 404 handling, move templates to typo3conf/ext/templates (best search-replace all paths in a dump of the db!), tidy up users and groups, move all templates from db to includes, clean up template structure etc etc - it all depends on the time you have available for that site.
Make the backup. Again.
Test and deploy
Test it on a live server! Or, if it's not a high profile site that can afford some downtime, just go live, moving files (without typo3temp) and db to the server, setting the symlinks, clearing all caches etc.
On the live system, check the install tool. Probably you'll have to adapt some php.ini settings. And set the configuration preset to "Production".
Rebuild the reference index
Check "Reports". Regarding the case sensitivity issue, you might now see missing references here - you haven't seen those on the Mac, as you the file system was case insensitive. Also, you can query sys_file for missing = 1. You could re-run the scheduler FAL task mentionned above locally to see it can fix some filenames. If there are no other means, you could still rename all files to lowercase, cf. How do I rename all files to lowercase?
Check the cronjobs and scheduler tasks (go to "Check configuration" in the scheduler module as well, see if cli user exists). Ah, also see if you're running a current php version. Also check if you don't forbid google to crawl the live version in robots.txt
Do you have to configure some backup routines or update scripts? Do it now.
And don't panic if it's not working yet. Probably it's just the cache. Or something else.
When the site has been running to satisfaction for some time, run another dbcomp and delete all old tables.
Wait. What did I forget? Will add that later.
Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer).
I am a newbie with installation products ie., install4j
I am having trouble getting a same set of files installed in different folders ( based on their existence )
say for following three folders
C:\company\lib
C:\company\32bit\lib
C:\company\64bit\lib
if they are present; then I should copy a set of jars there.
I tried having three different "Install files" section under Installation component. At any point of time I am getting only one set of "Install files" getting to work. ie., if I have lib and 64bit\lib.. then it is getting copied one of the folders and proceeds with the Program Group...
Or is there a simpler way to do this?
You have to configure different file sets on "Files->Define distribution tree". See this help topic for an explanation.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
I am currently coding with Eclipse PDT, and I need to synchronise the files on my workstation with the files on the FTP server.
I've installed RSE, but I can only download and edit files as far as I can see it. What I want to happen is when I hit save, the file is saved locally, and the file to be updated on the FTP site.
Any ideas of how I can achieve this?
Create an ant builder on your project. See this article about how to do that. The important things you should know after you read the article:
You can use Ant FTP task to
transfer the files.
You can define properties given by
the Eclipse platform to get project
root, list of changed files, change
type (add, modify, delete) and so on.
Use them wisely. You will need
project_loc, resource_loc and so on.
See picture at end to see how to get
other available variables that can be
passed to the script.
Tune your Ant script, since if it run
for each file update, then it can be
slow. If it is slow anyway, then you can create a builder plugin for eclipse, which is not so complicated. I created some before.
Be prepared, that ant script can get
not only one file as changed, but a
list.